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

Figure out if caching locality lb endpoints breaks xDS protocol #11

Open
slonka opened this issue Sep 19, 2019 · 1 comment
Open

Figure out if caching locality lb endpoints breaks xDS protocol #11

slonka opened this issue Sep 19, 2019 · 1 comment

Comments

@slonka
Copy link
Contributor

slonka commented Sep 19, 2019

During development of #10 we stumbled upon an issue of caching (see related issue for full story). We should investigate if it breaks https://github.com/envoyproxy/data-plane-api/blob/master/XDS_PROTOCOL.md and report that to java-control-plane if it does. Also our fix for this issue is to not remove a service completely from serviceNameToInstances map - that would cause envoy to return 503 (no instances in a cluster) instead of 404 (no cluster)

@Automaat
Copy link
Contributor

Automaat commented Apr 2, 2022

I have checked it and it breaks xDS protocol. It is mostly problematic for services with * in dependencies. When we have * in dependencies we try to extract snapshot configuation for services that does not exist any more but are present in envoy-control ServicesState. And if we cannot extract this config Envoy cannot fully start. I think that because we don't remove services from serviceNameToInstances map there was neeed to copy SimpleCache from java-control-plane and add custom logic to sent EDS config for not existing services.

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