[chef] Re: Re: Re: Re: Re: Re: Re: Data Bag Search Delay

[Noah Kantrowitz < >]

Why not have your recipe read directly from the API service?

--Noah

On Oct 3, 2013, at 2:55 PM, Greg Zapp 
<
 >
 wrote:

> Hi Jay,
> 
> Because the last writer wins I'm have explicit producer/consumer channels.  
> The node is responsible for writing node attributes, the API server will 
> write to certain data bags, etc.
> 
> 
> On Fri, Oct 4, 2013 at 10:51 AM, Jay Feldblum 
> <
 >
>  wrote:
> Greg,
> 
> Node-specific data ("Create a data bag for each node") probably belongs on 
> the node directly, not in a data-bag item. You can modify the persistent 
> node data with `knife node edit $NODE`.
> 
> Write access from recipes to anything on the Chef-Server is probably a bad 
> idea (except for saving the node data at the end of a run).
> 
> Cheers,
> Jay Feldblum
> 
> On Thu, Oct 3, 2013 at 5:41 PM, Greg Zapp 
> <
 >
>  wrote:
> Thanks too Zac... I may be able to create more data bags than I originally 
> planned to ease the pain of iterating.  Would be nice if Chef used 
> something like couchbase or even upgraded to Solr4 with their soft commits 
> though.
> 
> I'm also setting up a "shared" hosting environment like Steven and in load 
> balanced pools to boot.  I find myself debating whether I should bother 
> implementing certain stuff in Chef, or just do it through our agent(it can 
> run jobs) more frequently as I get into the devilish details.
> 
> @Steven: I have a few ideas around this myself.
> * Create a data bag for each node and place the domains it needs in there.  
> Then you can iterate over all items efficiently.  You can also setup the 
> domain on multiple hosts for migrating services easily enough.
> * Have nodes remove data items after working them.  Implement a unique ID 
> and revision numbers.  This will allow updates and give the node the 
> ability to detect which item is the latest.  Store the info into node 
> attributes(or at least the revision number) and save before removing the 
> data item from the bag.  This will keep the domain bag cheap to iterate and 
> create a job queue of sorts.
> 
> I have other ideas but can't recall them all just yet; it's too early.  
> Looking forward to what others suggest.
> 
>

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