[chef] Re: Wrapper Cookbooks and Computed Attributes

[Ranjib Dey < >]

which version of chef you are running? you can do it in both way, chef 11 has elaborate and reliable attribute precedence methods. You have to use different precedence levels, at different part of the code.

i like roles, we have berkshel which maintains all community cookbooks with versions , all custom cookbooks are under site-cookbooks/ , and all of them starts with pd-* , all of them includes pd-base, which provides a library method VERSION, pretty much like rubygems, same is available as node attribute to. Which you can exploit in your recipes. We do have roles and different levels of attribute precedence. We use strict attribute conventions, (default always, use override only if its needed ), we use chefspec to test role+recipe together.


 But again, it really depends upon your workflow. How you manage cookbooks? What tools you use etc. If you are using something like knife-spork & berkshef/librarian, how comfortable you/your team with chef & ruby etc. I

On Wed, Aug 14, 2013 at 8:05 PM, Justin Locsei < " target="_blank"> > wrote:

I'm sure that I'm missing something very simple and self-evident, but I'm at a
bit of a loss as to how to handle computed attributes using override statements
in wrapper cookbooks.  I'm trying to follow what seems like the advice of the
wise men of Chef and use versioned wrapper cookbooks instead of roles, but
doing so seems like it involves sacrificing the ability to override a default
attribute for a cookbook and have that overridden default value be used in
computing other attributes.

For example, say I have a cookbook called "example".  In its
attributes/default.rb file, it has these two lines:

default['example']['version'] = '1.0'
default['example']['module'] = "example-#{example['version']}"

By default, the value of node['example']['module'] should be properly set to
"example-1.0".  If I set the version to "1.1" using a role, I can access
node['example']['module'] in a recipe, and its value should be "example-1.1",
which is great.  However, if I set up a wrapper cookbook named
"mycompany-example" and have its attributes/default.rb file contain the line
"override['example']['version'] = '1.1'", accessing node['example']['module']
in a recipe will give me a value of "example-1.0", even though accessing
node['example']['version'] would correctly be '1.1'.  The ideal outcome would
be to have the module value be "example-1.1", and I'm lost as to how to make
that happen.

If I'm reading the docs properly, it seems like attribute files are evaluated
in runlist order, so I imagine it'd be possible to just have
"mycompany-example" in the runlist, with no mention of the "example" cookbook,
and then add an "include_attribute 'example'" line after the override in the
attributes file.  However, the docs also say that dependencies specified in
metadata are loaded before the cookbook that depends on them, and I have the
"example" cookbook specified as a dependency in the "mycompany-example"
cookbook's metadata.rb, making it so that the "example" cookbook's attributes
file has already been loaded by the time I try to override an attribute that it
uses to compute other attributes.  I suppose I could remove that dependency,
but that seems wrong.

Does anyone have any experience with problems like this?  Any suggestions, even
if they're to throw out this approach and go with something different, would be
greatly appreciated.