I never heard of SRV and had a overview look at the RFC. I believe this would be of great value including it and make it easier for new users to get a cluster setup running.
+1 Cheers Andy -- Andy Wenk RockIt! Hamburg / Germany GPG public key: https://pgp.mit.edu/pks/lookup?op=get&search=0x4F1D0C59BC90917D > On 7 Oct 2016, at 19:08, Jan Lehnardt <[email protected]> wrote: > > This sounds useful, +1 > > Best > Jan > -- > >> On 07 Oct 2016, at 03:57, Adam Kocoloski <[email protected]> wrote: >> >> Hi all, >> >> Lately I’ve been thinking about how to ease the onramp for users to get a >> clustered CouchDB setup running. I think the Kubernetes work shows a lot of >> promise. One of the aspects of that work is the service discovery element; >> each node in a cluster should be able to automatically find its peers and >> connect to them. Kubernetes accomplishes this using SRV records; a DNS >> lookup for a given named service will return the FQDNs of all the live >> members of the “Pet Set”. >> >> The SRV approach is enough of a standard[1] that I wonder if we ought to >> code for it directly in mem3. It’d eliminate the need for a “sidecar” >> container in Kubernetes deployments and I can imagine that it will prove >> more generally useful. The idea would be for mem3 to check if the CouchDB >> node is running in distributed node, and if it is, fire off a DNS lookup on >> the domain name, then attempt to connect with any other targets that are >> included in the record set in the DNS response. >> >> What do you think? If no one objects I’ll file a JIRA and see what we come >> up with. >> >> Adam >> >> [1]: https://tools.ietf.org/html/rfc2782 > > -- > Professional Support for Apache CouchDB: > https://neighbourhood.ie/couchdb-support/ >
