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"] = 1.1.1.1
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.
Thanks.
--
sh
________________________________________ From: Lamont Granquist < > Sent: Thursday, March 19, 2015 1:07 PM To: 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. > > 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. |
Archive powered by MHonArc 2.6.16.