Provserv is a wrapper ( and the name is made up ) - it does its own things as well, so it’s probably best to call it an application cookbook that’s depending on another application cookbook. It’s also business specific to us. The cobbler cookbook is meant to, in the end, be shared with the community.
The cobbler attributes that need to be set however, need to be set per environment. We’ll have several of the ‘provserv’ applications running, each in its own environment.
My question was about whether people generally re-namespace these attributes when you have a cookbook you’re depending on and you need to expose those configurable attributes to the user.
In our case, we’d be setting all these in a Chef environment. But, do I expose them as:
default[“provserv”][“dhcp”][“gateway”] = 220.127.116.11
and in the recipe:
node[“cobbler”][“dhcp”][“gateway”] = node[“provserv”][“dhcp”][“gateway”]
Or do I just document it via the README that 'Hey, if you use this provserv cookbook, you need to configure these [“cobbler”][“dhcp”] attributes for whatever your environment is".
I’ll take a look at the httpd and mysql cookbooks to try and grok what you meant by using LWRP’s instead for these configurations.
From: Lamont Granquist firstname.lastname@example.org
Sent: Thursday, March 19, 2015 1:07 PM
Cc: Hajducko, Steven
Subject: Re: [chef] Exposing attributes from cookbooks you depend on
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.
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
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