[chef] Re: Re: RE: Race Conditions


Chronological Thread 
  • From: Noah Kantrowitz < >
  • To:
  • Subject: [chef] Re: Re: RE: Race Conditions
  • Date: Fri, 27 Sep 2013 14:55:46 -0500

In Open Source this is correct. In Enterprise Chef this is the default but 
you could change the ACLs to allow it.

--Noah

On Sep 27, 2013, at 2:51 PM, Warren Bain 
< >
 wrote:

> AFAIK, a node cannot update another node's attributes. At least I hope so!
> 
> On Sep 27, 2013 9:03 PM, "Kadel-Garcia, Nico" 
> < >
>  wrote:
> Greg, I'm also pretty new to chef. But looking at the content of a Chef 
> server, I see a PostgreSQL database running in 
> /var/opt/chef-server/postgresql, so it looks like a database upload 
> operation. That implies atomic transactions, so uploads one at a time 
> sounds right.
> 
> From: Greg Zapp 
> 
> Sent: Friday, September 27, 2013 2:44 AM
> To: 
> 
> Subject: [chef] Race Conditions
> 
> Hello,
> 
> I have a few nagging questions about Chef.  One of them revolves around 
> potential race conditions in updating nodes and databags on Chef Server.  
> For the life of me I am unable to find any information on how Chef updates 
> node information on the server side.  Does it merge changed keys?  Does it 
> fully overwrite all json keys?  If a client run starts and then some 
> external force updates the node on the server, will node.save(s) on the 
> client overwrite that information?  What about data bags?
> 
> I would appreciate any information that could be provided on this topic.  
> I'm considering drastic measures to to my lack of understanding of the 
> internals:
> *Only nodes update their attributes
> *Databags have ONE writer, multiple readers
> *Desired state stored in data bags
> *Current state stored in node attributes or other data bags
> 
> @.@
> 
> 
> Thanks,
>    Greg

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail




Archive powered by MHonArc 2.6.16.

§