On Monday, July 30, 2012 at 4:20 PM, Irvin Fan wrote:
I’m new to chef and still trying to understand how it works. I searched the FAQ and couldn’t find the answer to this. Please forgive me if the question has been answered before.
Let’s say I have 100 nodes running chef-client daemon. If I update the config for those nodes in chef-server my understanding is that all those chef-clients will detect the changes for its own node and go ahead to do whatever the recipes say to do. How can I control the process synchronously. I don’t want all my 100 nodes updating at the same time because the update process may require restarting Apache. I know one way to do it is to run the chef-client in non-daemon mode. e.g. run “knife ssh chef-client” on nodes one by one. I’m wondering is it possible to still run the chef-client in daemon mode but control the process on server side so that the update happens one node at a time? Maybe I can update the setting one node at a time. But how can I know the chef-client on a particular node is done so that I can move to update the setting for next node?
There are a lot of different ways to handle this, depending on what your requirements are.
One way is the data-driven approach, where you pre-partition your fleet into smaller clusters, which you assign by role or node attribute. Then, you drive any config changes which require app restarts using data in roles or data bags, with the application version (or package that installs the app, whatever) set per-cluster. On a small scale, you might have something like:
node1[“my_app”][“cluster_number”] == 0
node2[“my_app”][“cluster_number”] == 1
Data Bag Item:
Then your recipes would figure out the version of the app to run based on their cluster assignment, which should be a no-op if you’re on the correct version already.
The only option for getting feedback about chef-client success or failure at the moment is to use exception/report handlers.