Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
From: Adam Kocoloski <kocolosk@apache.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
Subject: Checking for cluster peers using SRV records on startup
Message-Id: <38F54B23-2D65-463E-9768-323C9CB6AEE2@apache.org>
Date: Thu, 6 Oct 2016 21:57:44 -0400
To: dev@couchdb.apache.org
archived-at: Fri, 07 Oct 2016 01:57:57 -0000

Hi all,

Lately I=E2=80=99ve 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 =E2=80=9CPet =
Set=E2=80=9D.

The SRV approach is enough of a standard[1] that I wonder if we ought to =
code for it directly in mem3. It=E2=80=99d eliminate the need for a =
=E2=80=9Csidecar=E2=80=9D 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=E2=80=99ll file a JIRA and see =
what we come up with.

Adam

[1]: https://tools.ietf.org/html/rfc2782=