[chef] Re: Re: Simultaneous node edits

[Tensibai Zhaoying < >]

To complement this idea, see nodes as Phoenix servers,i.e. if you need to 
change the runlist, kill it and re-create it from scratch (this may involve 
backup/detach of datas prior to destruction and restore/attach datas as part 
of bootstrap in case of data nodes, including databases, file sharing nodes 
and so on)

That's a hard path to setup but it gives a great disaster recovery plan at 
end.

The other way is to 'stage' editions in scripts triggered by a node end of 
run with a run handler...  

Feel free to ask whichever way sounds best to you with some details on your 
current way of doing things, I don't wish to write a novel about each options 
;)

Le 1 juil. 2015 21:27, Noah Kantrowitz 
<
 >
 a écrit :
>
>
> On Jul 1, 2015, at 12:23 PM, Daniil S 
> <
 >
>  wrote: 
>
> > Hello. 
> > 
> > I'd like to know how people avoid collisions, while two simultaneous node 
> > edits take place. Some very common (and painful) examples from my 
> > practice: 
> > 1. Two sysadmins +/- simultaneously issue 'knife node edit' on the same 
> > node. First of them who save edits will lost them because of the save of 
> > the second admin; 
> > 2. Person for sure lost his edits if he try to 'knife node edit' while 
> > chef client runs on this node. And you can't predict it even if you are 
> > single person who can manage nodes because chef may run as a daemon or 
> > via cron. 
>
> The Chef API is full of these race conditions. Generally the best approach 
> is to not use `knife node edit` and when you need to do some kind of bulk 
> update, have a "talking stick" negotiated out of band (usually in a chat 
> room). For non-node objects this is "fixed" because the authoritative 
> source of truth is source control and the second user would get a merge 
> conflict. 
>
> Node data should be set once at bootstrap and then never changed. If you 
> need to bring up a new node, do that instead. 
>
> --Noah 
>