Couchbase community cookbook: New nodes cannot join existing cluster


#1

ohai chefs,

I’m trying to use the community cookbook for couchbase and I’ve been
running into some trouble. I wasn’t sure if I should open an issue on the
cookbook repo, but figured I’d ask here first in case I’m overlooking
something.

I’m trying to setup two new couchbase servers to share a new cluster (we
are evaluating couchbase as a replacement for memcached). I have a wrapper
cookbook for couchbase which sets node[‘couchbase’][‘server’][‘username’]
and node[‘couchbase’][‘server’][‘password’] to be the same thing, which in
theory should create a default cluster with the same login info (see
https://github.com/juliandunn/couchbase/blob/master/recipes/server.rb#L134-L139).
This is indeed what happens, but both nodes as they are bootstrapped create
their *own *clusters instead of sharing one. Digging into the LWRP, it
looks like create_if_missing will connect to localhost, and never attempt
to connect to an existing cluster (
https://github.com/juliandunn/couchbase/blob/master/libraries/cluster_provider.rb#L18-L24
and
https://github.com/juliandunn/couchbase/blob/master/libraries/client.rb#L5-L7).
So, for a node’s first run, create_if_missing will always create a cluster
consisting of a single node. Subsequent runs on that node will see the
local cluster, but never one consisting of more than the single node.

Has anyone used this cookbook successfully for this purpose? With this
behavior, clusters are not very useful. Following the code, it makes sense
why it’s not working. I’m happy to investigate changing and fixing the
cookbook, but I wanted to see if this was a misuse first. I think the
solution would be to perform a search for all couchbase servers, see if the
cluster exists for any of them, and then attempt to join that cluster. Or,
an IP could be specified to connect to as a member of the cluster to join.

Any input is much appreciated!

Thanks,
Chris


#2

Hi Chris,

I’m the maintainer of that cookbook, so I guess I’m somewhat
responsible :slight_smile: That does sound like an issue; email me & let’s
discuss offline.

  • Julian

On Wed, Sep 11, 2013 at 2:28 AM, Christopher Armstrong
chris@chrisarmstrong.me wrote:

ohai chefs,

I’m trying to use the community cookbook for couchbase and I’ve been running
into some trouble. I wasn’t sure if I should open an issue on the cookbook
repo, but figured I’d ask here first in case I’m overlooking something.

I’m trying to setup two new couchbase servers to share a new cluster (we are
evaluating couchbase as a replacement for memcached). I have a wrapper
cookbook for couchbase which sets node[‘couchbase’][‘server’][‘username’]
and node[‘couchbase’][‘server’][‘password’] to be the same thing, which in
theory should create a default cluster with the same login info (see
https://github.com/juliandunn/couchbase/blob/master/recipes/server.rb#L134-L139).
This is indeed what happens, but both nodes as they are bootstrapped create
their own clusters instead of sharing one. Digging into the LWRP, it looks
like create_if_missing will connect to localhost, and never attempt to
connect to an existing cluster
(https://github.com/juliandunn/couchbase/blob/master/libraries/cluster_provider.rb#L18-L24
and
https://github.com/juliandunn/couchbase/blob/master/libraries/client.rb#L5-L7).
So, for a node’s first run, create_if_missing will always create a cluster
consisting of a single node. Subsequent runs on that node will see the local
cluster, but never one consisting of more than the single node.

Has anyone used this cookbook successfully for this purpose? With this
behavior, clusters are not very useful. Following the code, it makes sense
why it’s not working. I’m happy to investigate changing and fixing the
cookbook, but I wanted to see if this was a misuse first. I think the
solution would be to perform a search for all couchbase servers, see if the
cluster exists for any of them, and then attempt to join that cluster. Or,
an IP could be specified to connect to as a member of the cluster to join.

Any input is much appreciated!

Thanks,
Chris


[ Julian C. Dunn jdunn@aquezada.com * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]