[chef-dev] Re: Idiom for adding a node to a Cluster

[Bryan Taylor < >]

I like it. I hadn't thought of pushing the state data to some external location. That solves all the complexities around finding the master or dealing with down/hung nodes.

Can this process be made generic enough, though to be fit for use in a community opscode cookbook? Where can the "backup location" be defaulted to? It'd be nice if the chef server could always be used as a file server.

From: Graham Christensen < "> >
Date: Tuesday, October 15, 2013 6:47 PM
To: Bryan Taylor < "> >
Cc: Chef Dev < "> >
Subject: Re: [chef-dev] Idiom for adding a node to a Cluster

I currently have a mode attribute identifying the cluster it is part of. Every X hours a backup / snapshot is made, and a new node auto detects and imports the latest snap from the cluster by name (foocluster-201310151830.tar.gz for example) which includes all the info to join and catch up to the cluster. 

Hope that helps. 

Ps - this is really easy on AWA et al, a bit trickier on bare metal. 

Graham

On Tuesday, October 15, 2013, Bryan Taylor wrote:

I'm wondering what the chef idioms are for a certain problem that comes up a lot when expanding a cluster. Let's say I have some kind of persistence store and I want to enable replication, or add a new node with replication to an already running cluster. The replication will communicate on some custom protocol, but in order to work, I have to move stateful data, like db logs or whatever, from the master to a new node. The master is "the master right now", so it needs to be dynamically discovered, and accessed via rsync or scp, say,  to pull the files down. I'm thinking for this I should just provision every cluster node with a fixed static public/private key.