[chef] Re: Re: Changes to run_list (sometimes) won't stick!

[Mike Williams < >]

On 04/11/2010, at 16:14 , Paul Paradise wrote:

> I believe the client needs to have some form of locking or revision control 
> to really make this problem go away - optimistic locking wouldn't be too 
> difficult to retrofit, but something with vector clocks and an archived 
> history would allow for more intelligent merges of conflicting data than 
> "last one wins."

How about the idea of teasing apart node "config" data from "status" data.  
The server would be the source of truth for the "config", and the node itself 
the source of truth for it's "state".

Something like optimistic locking would still be desirable to prevent 
concurrent changes to the "config", but at least the node would be able to 
continue to communicate it's "state" to the server.

> I've been working around it for now by extending the client run interval 
> (reducing the likelihood of a race condition) or just eliminating the 
> chef-client's daemon process entirely. Certain critical nodes I only run 
> chef in an attended fashion - thereby ensuring that I get a consistent 
> state. Unfortunately, not the greatest workaround. :-(

Thanks Paul.  Not ideal, as you say.  But it's nice to know it's a real 
problem, and not (just) my own stupidity.

-- 
cheers, 
Mike Williams