It is ‘possible’ to do this with Chef, though I can’t guarantee Chef will
do it well. This sort of coordination is not what Chef excels at, and if
it is really important I would recommend using something better at
coordination, like Zookeeper. That said, here are some possible Chef
Use a library file to make an API call to some endpoint that distributes
your locks, this can be something hacked up in Chef server, or a different
service (like Zookeeper or Chubby). Have the result from this library call
block the recipe if you can’t get the lock.
Node Attributes can work, but you need to be careful. You can set a
particular attribute when you ‘have the lock’ and then always search for
that attribute on any nodes before you do you dangerous operation. There is
no built in locking mechanism, so you will need to wrap it very carefully.
I would not recommend it.
Databags are another option. These have many of the same caveats as
using Node attributes as it is hard to guarantee and atomic update. The
most likely failure scenario is two nodes read that no one has the lock and
both try to add it. Since databags always overwrite with the latest data,
they will both ‘write’ the lock and proceed to cheerfully destroy data.
To do this sort of thing properly, you will want a system than can do an
atomic compare-and-update, which is not what Chef was designed for in Node
attributes and Databags. There may be some other subsystem that can
perform this, but I cannot think of it right now.
On Thu, Nov 14, 2013 at 9:14 PM, firstname.lastname@example.org wrote:
I have a set of servers that need run chef-client at 30 min. interval.
Any of them have to execute an operation at any given time but can’t have
more then one at the same time.
I’m looking to make a lock(mutex) that is saved onto the chef server by
My question is how can I save it ?
- use a node attribute and all other will do a search for it
- make use of a databag(need to distribute keys to be a client on nodes)