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


Chronological Thread 
  • From: Daniel DeLeo < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: Re: Re: Re: Chef 11 Attribute Changes -- Computed Attributes Edition
  • Date: Fri, 9 Nov 2012 11:45:01 -0800

On Wednesday, November 7, 2012 at 12:03 PM, Phil Dibowitz wrote:
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?
In Chef 8-10, everything is based on merge order. There is a "combined_default" _method_ on Chef::Node::Attribute, but it's a computed value, based on a merge of cookbook, role, and environment defaults. 
 

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.
This is valid, so we fixed it. Attributes files will load in run_list order in Chef 11. Caveats to be aware of:
* dependencies load before the cookbook that depends on them, so if you have cookbooks in your run_list with dependencies on each other, the depended-on cookbook could load before its position in the run list.
* The expanded run_list doesn't know if/how you're using include_recipe(). Generally when using include_recipe you also specify a cookbook level dependency, so you can count on the depended-on cookbook being evaluated first, but the order may not match exactly.
* Dependencies in cookbook metadata are not ordered, so there is no way to specify in which order dependencies get evaluated. We sort them to enforce a repeatable order.

`include_attribute` can still be used to force an attribute file to load before another.
 

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.
Implementing it as merge order was counterintuitive and artificially limiting for many people, so we're not going back to that, but you're right that there should be a way to have runtime logic win over role data. To that end, we've added a precedence level to replace the "recipe default" and "recipe override". You can access it with `node.default![:key] = "value"` and `node.override![:key] = "value"`. This is available everywhere, so you could use it in an attributes file if you had a need.
 

--
Open Source software and tech docs Insanity Palace of Metallica

"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


-- 
Daniel DeLeo




Archive powered by MHonArc 2.6.16.

§