On 08.03.2013, at 19:30, Judd Maltin <[email protected]> wrote: > > > > 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.
data bags are a very different beast. I very rarely use data bags. most of the time for things which do not directly relate to a node data. a users data bag for instance. or to describe data for a application. but most of the time I try to use attributes if possible. the thing is: data_bags capture sort of desired state but are not changed if convergence of a node did not happen or go wrong or ... attribute data on the other hand is transient on the chef-client run until it run is successful (on the fly password creation in a failed chef-client run -> password is gone if you do not safe the node object back to the server) > [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. Spiceweasel for me is a workflow optimization. It lets you batch process knife commands. nothing more nothing less. but I try to move on to https://github.com/chef-workflow/chef-workflow-tasklib for this kind of stuff. much more powerful > > * 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. you still could use databags with application cookbooks like i think the main point to take away is to - have attributes (node attributes) in any upstream library cookbook) - alter/customize them with an application cookbook call it whatever you like ("AttributeInj") or anything IMHO crowbar can use two approaches: - make the crowbar app update data_bags und the wrapper-cookbooks apply the attributes in the run (the cookbook does not need to know about crowbar endpoints at all, but then maybe the solr update issue will bite again) - write a lib in chef to access the crowbar rest endpoint to fetch data. now we couple the wrapper-cookbook to the crowbar API. but still the cookbooks themselves can be used without crowbar. We practice this nova-cookbook wrapper-nova-cookbook style at the moment as a kind of best of both worlds. (and be able to use upstream cookbooks much more easily. > > > 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 yeah. In the long run I would try to do upstream-nova-cookbook crowbar-wrapper-nova-cookbook I don't know what is more (useful) work: extract attributes of the current crowbar cookbooks into wrapper cookbooks, or create new wrapper cookbooks using either the databag or the api call approuch around upstream cookbooks > > > > -- > 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/ -- DI Edmund Haselwanter, [email protected], http://edmund.haselwanter.com/ http://www.iteh.at | http://facebook.com/iTeh.solutions | http://at.linkedin.com/in/haselwanteredmund
_______________________________________________ Crowbar mailing list [email protected] https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
