[chef] Re: Re: Re: Re: Re: Re: Chef 11 Attribute Changes -- Computed Attributes Edition


Chronological Thread 
  • From: Phil Dibowitz < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: Re: Re: Chef 11 Attribute Changes -- Computed Attributes Edition
  • Date: Wed, 7 Nov 2012 12:03:49 -0800

On Wed, Nov 07, 2012 at 11:48:44AM -0800, Daniel DeLeo wrote:
> Mostly it comes down to the fact that attributes files are implemented via 
> `instance_eval` on the node object, rather than having a defined DSL. I'd 
> initially written this change so that attributes files would be evaluated 
> in the context of a special DSL object, but we decided that this change 
> needed more design and research so we had to drop it in the interest of 
> shipping Chef 11.
> 
> The only other obvious way to accomplish what you're asking for is to put 
> the node object into "attribute-file-mode" or "recipe-mode", but this 
> carries the risk that you get stuck in the wrong state. Given all the ways 
> people use Chef's libraries to automate mangling of node data, it seems 
> pretty likely that this would occur.

But you keep track of them separately, right? So at read time, why can't you
just pick the same one you used to pick?

> If what you really wanted in the first place was something like a
> runtime-evaluated role, you could implement that as a cookbook with all the
> logic you want in the attributes file.

No, because those aren't evaulated in run_list order. Our attributes files
setup all basic data-structures. Then our recipes all add/change/munge data in
a sane way, based on runlist order: basic company-wide cookbooks, then
cookbooks that apply to large swaths of servers, then cookbooks that are more
specific. Each one can change the data.

We rely *heavily* on templates, so I all the early cookbooks setup those
templates, everyone has plenty of time to add to the data in recipes or roles
as necessary, and then the template will get the most appropriate data.

> Alternatively, you can use local variables instead of node attributes as the
> final input to your recipes. Your logic would be the same, and in the same
> place, you just assign the final value to a local instead.

No, because that's all compile-time. I need the templates to get the data
provided by cookbooks that run after them.

> If you really want the value to be set as a node attributes, you can simply
> go around the precedence system by accessing
> `node.attributes.role_override`.

I could also do node.override, but that's silly. The precedence system was
logical before. Having data that is evaluated at *upload* time override data
computed at *runtime* is counter-intuitive and limiting and defeats the
original beauty of the predence system.

-- 
Phil Dibowitz                             

Open Source software and tech docs        Insanity Palace of Metallica
http://www.phildev.net/                   http://www.ipom.com/

"Be who you are and say what you feel, because those who mind don't matter
 and those who matter don't mind."
 - Dr. Seuss

Attachment: signature.asc
Description: Digital signature




Archive powered by MHonArc 2.6.16.

§