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

pre define shunt backend in case routegroups are used #289

Open
szuecs opened this issue Jan 14, 2021 · 3 comments
Open

pre define shunt backend in case routegroups are used #289

szuecs opened this issue Jan 14, 2021 · 3 comments

Comments

@szuecs
Copy link
Member

szuecs commented Jan 14, 2021

I am not sure if it makes sense, but a user had the idea to pre define shunt backend in case routegroups are used, such that they don't need to define additionalBackends. I documented additionalBackends now in #288

@mikkeloscar
Copy link
Contributor

I had the same idea when implementing RouteGroup support and agree that this could reduce the boiler plate needed by users. What I wonder though if is shunt could be made special in RouteGroup in general so you don't have to define it also in a plain RouteGroup (outside of StackSet)?

@szuecs
Copy link
Member Author

szuecs commented Jan 19, 2021

@mikkeloscar I don't think so, because for RouteGroup in skipper this is just one of our supported backends and why should we add special things for shunt and not for loopback. I think the less magic a building block is the better.
Adding this to stackset makes sense because we abstract here ingress/routegroups anyways.

@mikkeloscar
Copy link
Contributor

From my perspective any of the backend types where there is no additional configuration possible could be automatically available.

I think the less magic a building block is the better.

I agree when we think of it as a building block. However when users has a desire to write RouteGroups directly, then I can see the value in some "magic" such that it becomes less verbose.

Adding this to stackset makes sense because we abstract here ingress/routegroups anyways.

Agreed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants