- From: Mike Williams <
- Subject: [chef] Re: Re: Changes to run_list (sometimes) won't stick!
- Date: Thu, 4 Nov 2010 17:40:32 +1100
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.
Archive powered by MHonArc 2.6.16.