-
Notifications
You must be signed in to change notification settings - Fork 79
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
[FEATURE] Admiral RFC: Client API #132
Comments
@jwebb49 Nice proposal! Currently istio's merge semantics do not allow virtual services to be merged for sidecars (only allowed at Gateway). We need this before we can implement the proposed design. As far as I can think, we cannot achieve this without support in Istio. Also, not clear about reusing the istio's API part, are you referring to an existing API or a new one that will be built? Would be good to clarify that. |
|
@aattuluri the goal would be to have one VirtualService and use logic in admiral to merge the Client type with the existing VirtualService (VS) and DestinationRule (DR). The part I am not sure about would be to place the merged VS and DR in the client namespace or override the services VS and DR. I was thinking to reuse the existing Istio API and not wrap it. WDUT? |
…ystem#132) * Fixes: istio-ecosystem#234 force GTPs to update only Signed-off-by: Shriram Sharma <[email protected]> * fixed linting errors Signed-off-by: Shriram Sharma <[email protected]> Co-authored-by: aattuluri <[email protected]>
Create a way for clients to set timeouts, retries, circuit breakers, faults, and time delays that only apply to that specific client of the service and no other clients. This API designs and introduction of a new type will prevent the client from having access to the more sensitive routing, security, and load balancing configuration used by the service and not relying on the service team to make changes on the client’s behalf.
Details
The text was updated successfully, but these errors were encountered: