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.
>
>
Archive powered by MHonArc 2.6.16.