> -----Original Message----- > From: crowbar-bounces On Behalf Of Ralf Haferkamp > Sent: Thursday, March 07, 2013 11:16 AM > To: crowbar > Subject: Re: [Crowbar] Attribute injection > > Hi, > > On Wed, Mar 06, 2013 at 07:36:25PM -0600, [email protected] 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. >
Logging and ntp probably fall into the simple category. A couple more interesting ones are DHCP and Provisioner. Both of these need to have a list of all the nodes known to crowbar injected into them, for the recipes to use. Settling on a pattern there would probably be a great start for other places where we currently do search. > > (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 :) > (un?)Luckily crowbar won't support that method ;) > > 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. > True, that's why it's on the list ;) The thing is that in cb1.0 we tried a couple of times, and the chef-client failed, we'd give up. Also, reporting about what exactly failed, and why was.... less than stellar. This brings up another item of internal discussion, that ties closely to AttrInj - Single Role Chef runs. (I'm tempted to continue here, but this topic might be better suited in a thread of its own, that I'll start shortly). > > 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: > > > [..] > So, in the original email I neglected to close the loop about jobs & search relationship.... In Approach b), a barclamp specific job can be injected into the job DAG, at the appropriate spot, to perform the search against the database, and provide the required information back into the attributes being injected. > -- > Ralf > > _______________________________________________ > Crowbar mailing list > [email protected] > https://lists.us.dell.com/mailman/listinfo/crowbar > For more information: http://crowbar.github.com/ _______________________________________________ Crowbar mailing list [email protected] https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
