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

Service discovery topological affinity #686

Open
enxebre opened this issue Mar 29, 2016 · 2 comments
Open

Service discovery topological affinity #686

enxebre opened this issue Mar 29, 2016 · 2 comments

Comments

@enxebre
Copy link
Contributor

enxebre commented Mar 29, 2016

For service to service communication we should be able to put a solution for discovery giving priority to the instances in the same topological domain, e.g a service in az1 should be able to see first services in the same az than services in az2
Something like internal communication proxies with restricted scope per az

@enxebre enxebre changed the title Services affinity Service discovery affinity Mar 29, 2016
@enxebre enxebre changed the title Service discovery affinity Service discovery topological affinity Mar 29, 2016
@enxebre
Copy link
Contributor Author

enxebre commented Mar 29, 2016

A way of doing this could be: given a group of slaves with semantic topological metadata, Marathon constraints could use this metadata to distribute and restrict the habitat of a given app/group while consul could use the same info via SERVICE_TAGS to limit the scope of the discovery via "az1.qa.sensitive-service-name.service.consul"

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