[chef] Re: Exposing attributes from cookbooks you depend on

[Lamont Granquist < >]

On 3/19/15 12:51 PM, Hajducko, Steven wrote:
> How are people typically exposing the attributes that a cookbook you are 
> depending on may have?
>
> For example, I have a cobbler cookbook.  It has some attributes that are 
> required for configuring cobbler - things like DHCP, etc.
>
> Then I have my provserv cookbook that wraps it and does a few other things, 
> specific to our org ( installing some content into cobbler and such ).
>
> The provserv cookbook is what's included in the nodes runlist.  But - you 
> need to make sure those cobbler attributes get set, otherwise cobbler isn't 
> going to work right.
>
> Do you create the same attributes in the provserv cookbook and then overwrite 
> the cobbler ones?  ( ie: since I have a default['cobbler']['dhcp_start'] 
> attribute, do I make a default['provserv']['dhcp_start'] attribute that sets 
> the cobbler one? ).  Do you depend on the user to figure out that provserv is 
> depending on cobbler and they need to read the cobbler cookbook to see what 
> other attributes need to be configured?
>
> Just curious how others are accomplishing this.  Examples would be most 
> appreciated.
>
> Thanks
>
> Steve
If proserv is just a wrapper around cobbler then set the cobbler 
attribute in the proserve/attributes/default.rb file.

I don't know what proserve is, so if those are logically distinct then 
it may make sense to have a third cookbook (probably what you might 
consider a 'role' cookbook) which sets attributes for both of those 
cookbooks.

If cobbler and proserve always go together for a given role and that's 
how you expect they'll always be used, and you're writing all this from 
scratch, you could go the other direction and just make a role cookbook 
with two recipes/cobbler.rb and recipes/proserve.rb files (and a 
default.rb that just include_recipe's both of them) and then set all the 
attributes directly on that cookbook's attribute file -- you lose some 
flexibility of composition this way, but it reduces your cookbook count, 
and if you don't forsee needing the composition then YAGNI.

Its also often better to stop using attributes for everything and setup 
LWRPs the way the new httpd and mysql cookbooks are doing. then you 
could just have a role cookbook which used proserve and cobbler LWRPs 
and hard coded the parameters they were passed.  If those values are 
unlikely to vary in your infrastructure you don't necessarily need to 
expose tweakable attributes for everything (again YAGNI).  But, that is 
probably more refactoring than you want to do right now.

Those are the options, I suspect the first or second option is the one 
you want.