[chef] Re: Re: Re: Re: Understanding node attributes set from 'role' cookbooks

[Noah Kantrowitz < >]

On Mar 14, 2014, at 12:10 PM, Jesse Nelson 
<
 >
 wrote:

> Ensure load order of attributes by using incliude_attribute[1] in your 
> wrapper attributes. You can then replace the values of any of the 'library' 
> cooks attributes in your wrapper with the same attribute level. I.e.  
> default. 
> 

This isn't needed, they are already loaded in topographic-sort-order :-) 
load_attributes used to be needed more in the Chef 10 days when load order 
was undefined, but it should almost never come up anymore.

> In your wrapper you include_recipe[2] the library cook, and your attributes 
> will have taken precedence.  This imo Is the _sane_ way to wrap things.  
> 

The problem is you still can't (easily) force things into derived attributes 
without duplicating the logic.

> I personally avoid node.set as much as possible in my wrappers as it 
> persists to the node, and It gets hard to reason about what is going on. 
> Enforcing load order of attributes, recipes, and using default 'most' of 
> the time will make your life much more sane IMO. 
> 

> Are there any other tricks that I can do to force my wrapping
> cookbook's recipe to be evaluated before that of the cookbook with
> attribute logic?

Unfortunately no, the load order of these is fixed where _all_ attribute 
files are run (in topo order) and then recipes specified by the run list are 
run. My solution to this is unfortunately a tad complex and involves moving 
derived data to methods on my resource objects.

--Noah

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail