[chef] Re: Re: Re: Save from recipe data to chef server


Chronological Thread 
  • From: Silviu Dicu < >
  • To: " " < >
  • Cc: " " < >
  • Subject: [chef] Re: Re: Re: Save from recipe data to chef server
  • Date: Sat, 16 Nov 2013 13:11:12 -0500

Hi,

Can you elaborate on 'this can be something hacked up in Chef server'
From a node/client that is not admin on the open source chef you are limited 
to node attributes - unless there is a different way to do it.

The strategy check if exists is fine (I imagined the same).

thanks!



> On Nov 15, 2013, at 11:48 AM, Seth Falcon 
> < >
>  wrote:
> 
> 
> 
>  writes:
>> It is 'possible' to do this with Chef, though I can't guarantee Chef will
>> do it well.  This sort of coordination is not what Chef excels at, and if
>> it is really important I would recommend using something better at
>> coordination, like Zookeeper. That said, here are some possible Chef
>> solutions:
> 
> +1 on the caveats. Chef Server doesn't provide orchestration primitives
> at this time.
> 
> It is something that we discuss adding and it always helps to examples
> of what would be useful.
> 
>> 3. Databags are another option.  These have many of the same caveats as
>> using Node attributes as it is hard to guarantee and atomic update.  The
>> most likely failure scenario is two nodes read that no one has the lock and
>> both try to add it.  Since databags always overwrite with the latest data,
>> they will both 'write' the lock and proceed to cheerfully destroy
>> data.
> 
> While it really is not a good idea, if you are going go down this route,
> I'd recommend using the presence/absence of a data bag (not data bag
> item).
> 
>    api.post("data", {:name => "lock1"})
> 
> This will only succeed if there is not already such a data bag (returns
> 409 if a bag named lock1 already exists). Top-level data bags are about
> as light weight as you can get and get you closest to the atomic CAS
> thing.
> 
> + seth
> 
> -- 
> Seth Falcon | Development Lead | Opscode | @sfalcon
> 



Archive powered by MHonArc 2.6.16.

§