I'm being bitten by a race-condition when altering the run-list for a node (using either the Web UI, or "knife"). Sometimes, the changes just don't stick!
In particular, they don't stick if I make the change while "chef-client" is running on the node. The problem appears to be that chef-client saves the Node object at the end of it's run, reverting the run-list to it's previous state.
Someone logged a bug about this a couple of weeks ago:
but the problem appears to have existed for a while. I'm a little surprised that it hasn't been reported as an issue before now! I guess most people aren't in the habit of messing with run-lists that much ... at this stage, we're doing do mainly in automated tests for our provisioning scripts.
It seems weird to me that chef-client attempts to update the node's own "configuration" data, rather than just it's "status". Should there be a better separation between the two in Chef::Node?
Can anyone suggest how I might (a) work around the problem, or (b) fix it, in Chef::Node or chef-client?
Is it likely that changes to other Node attributes would be similarly affected, i.e. reverted at the end of each chef-client run?
Archive powered by MHonArc 2.6.16.