Open jpillora opened 8 years ago
Interesting feature. But I think this should not be done in the DNS. Why can't you add those 10 addresses to the loopback interface on those hosts? On 26 Jul 2015 08:20, "Jaime Pillora" notifications@github.com wrote:
I'm not sure if this feature is already possible or if would be possible a result of implementing #178 https://github.com/skynetservices/skydns/issues/178, if so, feel free to close this.
For example, let's say we have:
1.mydatabase.service 10.0.0.1 2.mydatabase.service 10.0.0.2 3.mydatabase.service 10.0.0.3
So mydatabase.service will round-robin through each as expected. However, it would be nice if 10.0.0.2 was priortised at the top for requests coming from 10.0.0.2 as it would prevent unnecessary network traversals. Thoughts?
— Reply to this email directly or view it on GitHub https://github.com/skynetservices/skydns/issues/213.
That would help in the case where a VM died and all containers on a single machine die at once. However, if container A dies, container B would still think A is on localhost. Whereas, if A had its address in skydns then it would expire and B would correctly route to a remote host.
I'm not sure if this feature is already possible or if would be possible a result of implementing #178, if so, feel free to close this.
For example, let's say we have:
So
mydatabase.service
will round-robin through each as expected. However, it would be nice if10.0.0.2
was priortised at the top for requests coming from10.0.0.2
as it would prevent unnecessary network traversals. Thoughts?Edit: This has the benefit of using a localhost instance of a given service when available and falling back to a remote host when not. Note, this scheme can manually implemented for custom clients, however with 3rd party clients using connection pools (redis/rethinkdb) this would not be possible without going into the source and introducing "primary" and "secondary" hostnames.