- 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.