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: https://tickets.opscode.com/browse/CHEF-1812 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? -- cheers, Mike Williams |
Archive powered by MHonArc 2.6.16.