On Thu, Mar 7, 2013 at 2:38 PM, <[email protected]> wrote: > Comments prefixed with [aa] (outlook goes nuts with HTML formatted > messages) > > From: crowbar-bounces On Behalf Of Judd Maltin > Sent: Thursday, March 07, 2013 2:07 PM > To: Ralf Haferkamp > Cc: crowbar > Subject: Re: [Crowbar] Attribute injection > > Hi Ralf! > > > a) With pure Chef - via the default attributes in the cookbook, the > > environments facility of Chef, or roles > > > > b) In Crowbar - crowbar will compute and inject override values for > > these attributes, at runtime, via chef API's. > Just out of curiousity. How will that be done? Will crowbar create roles > with > the attributes via the API or directly assigne the attributes to the node > objects? Or is there another approach? > > > [aa] - Both in crowbar 1.0 and 2.0 the idea is to use the Chef rest API, > via the Ruby classes in the chef gem. > > Our going model (chime in with different understandings) is that every node and every attribute have at least one role. Without some kinda unique role for each node and attribute, there can be no join. Except, of course, for the blazingly obvious automatic Ohai data.
> > > c) In other deployment systems - in a manner either like a) or b) > or > > telepathically. > ^^^^^^^^^^^^^^ I'd like to see the source code for that :) > FWIW, telepathy will not be necessary. Andi omits in option (a) a very > common pattern for many Chefs - "data bags." In fact, data bags are > generally preferred over roles for attribute injection. I'd recommend that > we create an "eventual consistency knob" pattern. It would allow the user > to dial in "search," "data_bag," or "Crowbar" as desired. > > > [aa] - Judd , imho there are a few issues with switching from node/role > attributes to databag based values: > > * There are no clear override semantics for data bags - you specify the > values in one place, and that's it. There a few cases where we rely on the > ability to set a safe default, and then override it on node-specific basis > when needed. > Yes, and the lack of override semantics in data bags keeps them "fresh." You must start your infrastructure with a good data bag, or change it to allow convergence. There's only ever one place where that data might be defined, which for "desired disposition" is exactly what one might want. (of course, for sanity's sake they should be tracked elsewhere.) it's akin to a Spiceweasel infrastructure.xml file, but spans the gap all the way to the resources. We may come across cookbooks we want to use that require them. Bluesky. > * The changes to the existing recipes are much larger. Rather than say > something like node["nova"]["api"]["endpoint"], you'd have to go load the > databag, find the item and use it. At this point, neither rcp, att or > crowbar uses a databag based pattern. > > Bluesky. Indeed, I'm not recommending this as the pattern we should follow, but as above, we might consider it a 2.1 feature to accept cookbooks driven by data bags (or any other data source accessible by a Jig-type barclamp's API) > I would suggest we keep changes relative to CB1.0 to a minimum around the > mapping of attributes to chef data, so we can ship this thing -- Judd Maltin T: 917-882-1270 F: 501-694-7809 what could possibly go wrong?
_______________________________________________ Crowbar mailing list [email protected] https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
