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. > (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 [email protected] https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
