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?
> 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. More coming on my blog soon.. soon. -judd On Thu, Mar 7, 2013 at 11:15 AM, Ralf Haferkamp <rha...@suse.de> wrote: > Hi, > > On Wed, Mar 06, 2013 at 07:36:25PM -0600, andi_a...@dell.com wrote: > > During the session today, I mentioned there's a proposal on the table.. > but > > it exists in mostly some threads & some heads. This is an attempt to > capture > > some of the mountain of items that make AttribInj. > > You've been warned - TL;DR. > > Thanks Andi, for this nice write up this really helps to better > understand the > whole concept. > > Btw, in case anybody else wonders that DAG stands for. Andi just mention > on IRC > that it's "Directed Acylic Graph". > > As one of our sprint goals is to migrate the Crowbar Cookbooks to attribute > injection I'd like to start working on that. Do you have any suggestion > which > barclamp would be a good starting point for that? I guess it's better to > start > with an easy one. Does logging fall into that category? Or ntp? > > I guess more questions will come up, when actually working on it. > > > (note to reader - the CB2.0 references are WIP, and not intended to be > > presented as a done deal, even if the language occasionally reads that > way) > > > > > > What's the problem: > > Chef is designed to be an eventually consistent system - clients will > > eventually get to the desired state. This typically works great. There > are 2 > > elements that make chef eventually consistent: > > > [..] > > > > The Solution(?): > > Attribute injection attempts to offer an approach that can solve or at > least > > alleviate these problems. Here's the general idea, then how it helps, and > > then some more details. > > > > In general, each recipe will define a set of attributes that are > required for > > it to run successfully. These attributes provide the information that > either > > search or crowbar would have provided. The attributes can be populated in > > different ways, depending on the environment in which the recipes are > used: > > > > 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? > > > 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 :) > > > How does this help? > [..] > > > > > > > Changes for CB2.0 > > Much of the above is the same as CB1.0. What is different? > > > > > > 1) Default attributes as API, based on patterns agreed/discussed > with > > wider openstack community (or pilfered from other folks who've > open-sourced > > their cookbooks). A follow up email will describe the patterns we > discussed > > during the Jan/22 hack day [4] and with the general community. > > > > 2) Search result injection - there are a few options here, > > > > a. Postpone this, since we're short on time, and things to > eventually > > work - just retry forever if needed, but be explicit about reporting > status > > (and option to cancle). Keep recipes using search where currently used. > Hm, but especially this caused us quite some problems. Even if everything > is > eventually consistent, failing chef runs and red blinking lights in the > Crowbar > UI are pretty irritating. > > > b. The Jig/Job orchestration engine allows barclamps to define > custom > > "Jobs" that are executed as the proposal is rolled out (see below). > > > > Some background about jobs, and how search can be handled (since there > wasn't > > a whole lot of ML activity around jobs): > > When deploying a snapshot, there are many required steps - from > allocating > > the node, deploying each role in the right element order to the subset of > > nodes on which it applies, then deploying the next set of roles. A simple > > example might be Nova, when a user commits a snapshot for deployment: > > > [..] > > -- > Ralf > > _______________________________________________ > Crowbar mailing list > Crowbar@dell.com > https://lists.us.dell.com/mailman/listinfo/crowbar > For more information: http://crowbar.github.com/ > -- Judd Maltin T: 917-882-1270 F: 501-694-7809 what could possibly go wrong?
_______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
