You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: