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

[Jesse Nelson < >]

On Fri, Mar 14, 2014 at 12:39 PM, Noah Kantrowitz < " target="_blank"> > wrote:

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.

For me this is more about indicating intent, and readability for someone else on my team.  As we discussed on IRC this is also needed if you need to load specific attribute files in a specific order from the same cookbook. 

I also just feel safer being explicit vs implicit ordering.

 

> 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.

My approach here is to try and avoid deriving the attrib in the attributes file(s). I think we agree there.

 

> 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