> -----Original Message----- > From: crowbar-bounces On Behalf Of Abes, Andi > Sent: Thursday, March 07, 2013 1:32 PM > To: rha...@suse.de; crowbar > Subject: Re: [Crowbar] Attribute injection > > > > > -----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, 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. > > > > 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.
I would not try to make the cookbooks in the provisioner barclamp attribute driven right now. They might make ina interesting case study, but the functionality they implement is both tied pretty intimately with the rest of Crowbar and would not be made more comprehensible by removing 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 > > Crowbar@dell.com > > https://lists.us.dell.com/mailman/listinfo/crowbar > > For more information: http://crowbar.github.com/ > > _______________________________________________ > Crowbar mailing list > Crowbar@dell.com > https://lists.us.dell.com/mailman/listinfo/crowbar > For more information: http://crowbar.github.com/ _______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
