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
Does it make sense to overall make names for backends first class citizen in Skipper then? For sources that do not provide it (Ingress, direct eskip definition, etc.) that could be autogenerated like route names are (according to some sensible pattern). On the other hand isn't it much, is there any other use case that can be simplified/benefit from backends having names?
Maybe but not sure. The route objects can have filters, that can set any key/value combination. Just like how we set the tracingTag. Since the routes are usually generated from a higher level representation like the ingress, we can say that the current way is fine for the majority of the use cases. On the routing level, or when the input is in eskip format, it would make sense only if it was possible to define the backends as definitions separate from the routes, and the routes would only reference them by their name. Then it would be a similar scenario as what we have with the route groups.
Of course there can be other ways and use cases that I am currently missing.
#1495 introduced a way to get opentracing tag
skipper.backend_name
This https://github.com/zalando/skipper/pull/1495/files#diff-6174ff750fcb17e93febb4b1ee2aec34R727 would be nice if we could use the PreProcessor for default routes like in https://github.com/zalando/skipper/blob/master/skipper.go#L1179
The challenge is that we don't really always have a name.
The text was updated successfully, but these errors were encountered: