Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow ServiceEntry to be referenced from injected extensions #955

Open
louiscryan opened this issue Jun 24, 2019 · 0 comments
Open

Allow ServiceEntry to be referenced from injected extensions #955

louiscryan opened this issue Jun 24, 2019 · 0 comments

Comments

@louiscryan
Copy link
Contributor

Describe the feature request
Envoy extensions often need to talk to downstream services to function. We have a mechanism to declare these destinations, ServiceEntry, but not in a way that is usable for extensions.

In order to use ServiceEntry we need to solve a number of issues

  • We mangle cluster names that are generated for Envoy which makes it hard to refer to generated clusters in a stable way. The mangling is not considered stable.

  • We don't have a way to force clusters to be emitted for a ServiceEntry when there is a dependency on them in Gateways. We do have a way to do this in Sidecar.

Describe alternatives you've considered

Affected product area (please put an X in all that apply)

[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[X ] Networking
[ ] Performance and Scalability
[ X] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience

Additional context

There are other hardcoded clsuters in the system that we should consider modelling with ServiceEntry, e.g. passthrough, blackhole etc. If we are going to adopt an unmangled naming convention for these things then we should standardize naming so any built-ins can also be used by users in VirtualService, Sidecar and Gateway

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: P1
Development

No branches or pull requests

5 participants