-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Consider adding Route Discovery Service (RDS) API #298
Comments
Actually, this would be very useful. CDS would allow us to add upstream blocks, but without RDS, CDS alone would not be that useful. Ultimately, the route table is the place where one points to the cluster for a given path/host. So, RDS and CDS go hand in hand. |
@rshriram yes, that's my thinking. I think there are still many use cases for static route configs depending on deployment. (For example I don't really see Lyft moving away from that for a long time), but given that it's not that hard to implement, I think it could be useful for some use cases. |
@mattklein123 thinking about this a little more, we now have multiple components of the config files being obtained via 3 different REST api calls. (RDS, CDS, and SDS). My concern is that there are too many moving parts in this config, that could potentially be managed independently in an inconsistent manner. To put things into perspective, there are typically three mutations to the config file that happen during the lifetime of an Envoy process:
(1) is accomplished by the CDS proposal. However, any routing rule needs to refer to a cluster in order to be valid. Given this dependency, why not merge (1) and (3) (i.e., CDS and RDS) into one single service ? The APIs can be the same as the CDS apis that you recently proposed. Periodically, Envoy obtains the new routes and the clusters that these routes refer to (they can contain static IPs or SDS entries). Am I missing something here? |
@rshriram a few things:
In my mind, I think it's fine to have different API calls for the different use cases and decouple them and in the future allow cluster to refer to an unknown cluster. From an operator perspective, if the same backend server implements CDS/RDS, if the implementation wishes it can make sure that there are atomic updates. From the Envoy perspective, the cluster manager and the http router are totally different systems and I think having a single API provide both goes against the separation of concerns that are already in place. |
See istio/istio#30484 Signed-off-by: Taylor Barrella <[email protected]>
#30044) UNCLEANLY Revert " notifier: adding basic oncall notifications (#29820)" This reverts commit c495291. Signed-off-by: Alyssa Wilk <[email protected]>
Now that we have SDS and soon CDS, there is no reason that we couldn't also add "RDS." This would allow the HTTP connection manager to dynamically reload the route table via an API call. The implementation is not very complicated. There hasn't been any explicit request for this feature yet but I can see that we are heading in this direction so I thought I would file the issue.
The text was updated successfully, but these errors were encountered: