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

[FEATURE] Admiral RFC: Client API #132

Open
jwebb49 opened this issue Aug 6, 2020 · 3 comments
Open

[FEATURE] Admiral RFC: Client API #132

jwebb49 opened this issue Aug 6, 2020 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@jwebb49
Copy link
Collaborator

jwebb49 commented Aug 6, 2020

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

@jwebb49 jwebb49 added the enhancement New feature or request label Aug 6, 2020
@jwebb49 jwebb49 assigned jwebb49 and aattuluri and unassigned jwebb49 Aug 6, 2020
@aattuluri
Copy link
Contributor

@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.

@jwebb49
Copy link
Collaborator Author

jwebb49 commented Aug 7, 2020

@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.

@jwebb49 jwebb49 closed this as completed Aug 7, 2020
@jwebb49
Copy link
Collaborator Author

jwebb49 commented Aug 7, 2020

@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?

@jwebb49 jwebb49 reopened this Aug 7, 2020
itsLucario pushed a commit to itsLucario/admiral that referenced this issue Aug 9, 2022
…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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants