Excellent design talks here.  Thanks Ed!

1) Attributes

Crowbar hasn't (yet?) implemented a notion of attribute precedence within
or across barclamps.  Chef DOES have some fairly complex attribute
precedence for the various sources of attributes (node, role, env, data
bag.)  This leads to our question - where and how to inject attributes.

Crowbar needs to be told where the attribute should be set, and at what
precedence, UNLESS we can infer it from the as-of-yet implemented Crowbar
attribute precedence.  That seems like a long path not (yet? ever?) worth
taking.

So my takeaway with this though experiment is that the attribute map
included with the barclamp and matching the appropriate jig (Chef) MUST
express where in the Chef server the attribute will be read/written via the
ChefAPI.  This will allow us to be more flexible in picking up community
cookbooks and crowbarizing them.

As an overview: attributes and run-lists are our major primitives in
dealing with chef.

Attributes can be introduced via the ChefAPI via:
* data bags (usually not updated by chef-client)
   *
http://docs.opscode.com/essentials_data_bags_use_recipe.html#creating-and-editing-data-bag-within-a-recipe
* environments (usually not updated by chef-client)
   * http://docs.opscode.com/essentials_environments_formats.html
* roles (usually not updated by chef-client)
   * http://docs.opscode.com/essentials_roles_formats.html
* node attribute (always updated by chef-client)
   * avoid writing here, write on the node role unless the cookbook

So, the barclamp author will be responsible for ensuring that the
interfaces between the Jig and the Cookbook must remain connected by means
of the required attribute mapping, and optionally wrapper cookbooks to
clean up the interface.

Objections?  Headaches?  Rotten tomatoes?

Next post - run lists.


On Sat, Mar 9, 2013 at 12:23 PM, Haselwanter Edmund
<[email protected]>wrote:

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


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

Reply via email to