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

[Jesse Nelson < >]

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. 

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.  

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. 

[1] https://github.com/cloudware-cookbooks/ktc-messaging/blob/master/attributes/rabbit.rb

[2] https://github.com/cloudware-cookbooks/ktc-messaging/blob/master/recipes/default.rb

- Jesse

On Fri, Mar 14, 2014 at 11:59 AM, Lewis Thompson < " target="_blank"> > wrote:

On 14 March 2014 16:44, Noah Kantrowitz < "> > wrote:
> Move that logic into recipe or resource code so it can be lazily evaluated. The problem is that attribute files are run once at the start a run so having any logic based on values that might change later (either due to overrides or anything else) doesn't change the outcome of that execution (since it already happened).

Hi Noah

Thanks for your reply.  Am I correct in understanding that you mean
the attributes file logic should be moved into a recipe for lazy
evaluation?

I can understand how this would change the behaviour but in this
instance I am wrapping a third-party cookbook.  Adjusting that
cookbook would make tracking upstream changes difficult.

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?

thanks, Lewis