# Exposing attributes from cookbooks you depend on

**URL:** <https://discourse.chef.io/t/exposing-attributes-from-cookbooks-you-depend-on/6429>\
**Category:** Chef Infra (archive)\
**Created:** [March 19, 2015, 7:51pm UTC](https://discourse.chef.io/t/exposing-attributes-from-cookbooks-you-depend-on/6429 "2015-03-19T19:51:59Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![sjmh](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/sjmh/32/124_2.png) [@sjmh](https://discourse.chef.io/u/sjmh)\
**Post date:** [March 19, 2015, 7:51pm UTC](https://discourse.chef.io/t/exposing-attributes-from-cookbooks-you-depend-on/6429/1 "2015-03-19T19:51:59Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Lamont\_Granquist](https://avatars.discourse-cdn.com/v4/letter/l/d26b3c/32.png) [@Lamont\_Granquist](https://discourse.chef.io/u/Lamont_Granquist)\
**Post date:** [March 19, 2015, 8:07pm UTC](https://discourse.chef.io/t/exposing-attributes-from-cookbooks-you-depend-on/6429/2 "2015-03-19T20:07:36Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![sjmh](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/sjmh/32/124_2.png) [@sjmh](https://discourse.chef.io/u/sjmh)\
**Post date:** [March 19, 2015, 8:53pm UTC](https://discourse.chef.io/t/exposing-attributes-from-cookbooks-you-depend-on/6429/3 "2015-03-19T20:53:30Z")

</div>

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 [lamont@chef.io](mailto:lamont@chef.io)  
Sent: Thursday, March 19, 2015 1:07 PM  
To: [chef@lists.opscode.com](mailto:chef@lists.opscode.com)  
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.

---

<div class="post-metadata">

**Author:** ![Lamont\_Granquist](https://avatars.discourse-cdn.com/v4/letter/l/d26b3c/32.png) [@Lamont\_Granquist](https://discourse.chef.io/u/Lamont_Granquist)\
**Post date:** [March 19, 2015, 10:07pm UTC](https://discourse.chef.io/t/exposing-attributes-from-cookbooks-you-depend-on/6429/4 "2015-03-19T22:07:12Z")

</div>

On 3/19/15 1:53 PM, Hajducko, Steven wrote:

> 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"]

yeah, don't set that attribute in the recipe.

you probably set it in the recipe because you hit the interpolated  
attributes problem in the attributes file.

its better to just use default["cobbler"]["dhcp"]["gateway"] in the  
attributes file of the proserv cookbook.

---

<div class="post-metadata">

**Author:** ![tknerr](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/tknerr/32/21_2.png) [@tknerr](https://discourse.chef.io/u/tknerr)\
**Post date:** [March 20, 2015, 9:09am UTC](https://discourse.chef.io/t/exposing-attributes-from-cookbooks-you-depend-on/6429/5 "2015-03-20T09:09:33Z")

</div>

My preference on this is to re-namespace the attributes the user is  
expected to set. I think of it as the "public interface" of a wrapper  
cookbook that is tested and also documented in the README.

Cheers, Torben

On Thu, Mar 19, 2015 at 11:07 PM, Lamont Granquist [lamont@chef.io](mailto:lamont@chef.io) wrote:

> On 3/19/15 1:53 PM, Hajducko, Steven wrote:
> 
> 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"]
> 
> yeah, don't set that attribute in the recipe.
> 
> you probably set it in the recipe because you hit the interpolated  
> attributes problem in the attributes file.
> 
> its better to just use default["cobbler"]["dhcp"]["gateway"] in the  
> attributes file of the proserv cookbook.

---

<div class="post-metadata">

**Author:** ![Lamont\_Granquist](https://avatars.discourse-cdn.com/v4/letter/l/d26b3c/32.png) [@Lamont\_Granquist](https://discourse.chef.io/u/Lamont_Granquist)\
**Post date:** [March 20, 2015, 4:20pm UTC](https://discourse.chef.io/t/exposing-attributes-from-cookbooks-you-depend-on/6429/6 "2015-03-20T16:20:49Z")

</div>

That's ideal philosophically, but is probably going to produce bad chef  
code. One you've hit the computed attributes issue and worked around it  
by moving setting attributes in recipes and exposed yourself to  
compile/converge issues and started down the path of probably needing to  
use 'lazy' attributes, then I'd rethink the idea of re-namespacing the  
attributes.

On 3/20/15 2:09 AM, Torben Knerr wrote:

> My preference on this is to re-namespace the attributes the user is  
> expected to set. I think of it as the "public interface" of a wrapper  
> cookbook that is tested and also documented in the README.
> 
> Cheers, Torben
> 
> On Thu, Mar 19, 2015 at 11:07 PM, Lamont Granquist [lamont@chef.io](mailto:lamont@chef.io) wrote:
> 
> > On 3/19/15 1:53 PM, Hajducko, Steven wrote:
> > 
> > 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"]
> > 
> > yeah, don't set that attribute in the recipe.
> > 
> > you probably set it in the recipe because you hit the interpolated  
> > attributes problem in the attributes file.
> > 
> > its better to just use default["cobbler"]["dhcp"]["gateway"] in the  
> > attributes file of the proserv cookbook.

---

<div class="post-metadata">

**Author:** ![sjmh](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/sjmh/32/124_2.png) [@sjmh](https://discourse.chef.io/u/sjmh)\
**Post date:** [March 20, 2015, 4:24pm UTC](https://discourse.chef.io/t/exposing-attributes-from-cookbooks-you-depend-on/6429/7 "2015-03-20T16:24:57Z")

</div>

So I read over the httpd and mysql and saw what you meant about using LWRP's in lieu of attributes.

My question is - when's the right time to do this and when does it make sense to use normal cookbooks with attributes?

In my case, the cobbler cookbook is exposing LWRP's for some parts of it's configuration ( distros, profiles, etc ). Anything that you can have many of.

However, when you have a singleton service ( ie - the actual 'cobbler' server ), does it make sense to shove it into an LWRP or just stay with the the normal include\_recipe and some configuration attributes? Is there somewhere that I missed that using attributes for configuration driven recipes is a bad idea?

--  
sh

* * *

From: Lamont Granquist [lamont@chef.io](mailto:lamont@chef.io)  
Sent: Friday, March 20, 2015 9:20 AM  
To: [chef@lists.opscode.com](mailto:chef@lists.opscode.com)  
Cc: Hajducko, Steven; Torben Knerr  
Subject: Re: [chef] Re: Re: Exposing attributes from cookbooks you depend on

That's ideal philosophically, but is probably going to produce bad chef  
code. One you've hit the computed attributes issue and worked around it  
by moving setting attributes in recipes and exposed yourself to  
compile/converge issues and started down the path of probably needing to  
use 'lazy' attributes, then I'd rethink the idea of re-namespacing the  
attributes.

On 3/20/15 2:09 AM, Torben Knerr wrote:

> My preference on this is to re-namespace the attributes the user is  
> expected to set. I think of it as the "public interface" of a wrapper  
> cookbook that is tested and also documented in the README.
> 
> Cheers, Torben
> 
> On Thu, Mar 19, 2015 at 11:07 PM, Lamont Granquist [lamont@chef.io](mailto:lamont@chef.io) wrote:
> 
> > On 3/19/15 1:53 PM, Hajducko, Steven wrote:
> > 
> > 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"]
> > 
> > yeah, don't set that attribute in the recipe.
> > 
> > you probably set it in the recipe because you hit the interpolated  
> > attributes problem in the attributes file.
> > 
> > its better to just use default["cobbler"]["dhcp"]["gateway"] in the  
> > attributes file of the proserv cookbook.

---

<div class="post-metadata">

**Author:** ![Lamont\_Granquist](https://avatars.discourse-cdn.com/v4/letter/l/d26b3c/32.png) [@Lamont\_Granquist](https://discourse.chef.io/u/Lamont_Granquist)\
**Post date:** [March 20, 2015, 4:53pm UTC](https://discourse.chef.io/t/exposing-attributes-from-cookbooks-you-depend-on/6429/8 "2015-03-20T16:53:10Z")

</div>

We're heading in the direction where library cookbooks should only  
expose LWRPs for the most part. All the attributes should be exposed  
instead as parameters on LWRPs. Once those resources are mature then  
eventually they can get migrated into core chef.

Similar pattern can be used internally so that you'd have LWRPs to wrap  
your definition of what a generic 'application' is in your  
infrastructure so that the listen\_port becomes a parameter instead of an  
attribute. Then what attributes get used for is things where you'd like  
to twiddle them via roles or role cookbooks. So having one cookbook  
which manages /etc/resolv.conf makes sense, but then you might need to  
tweak the search path in different roles if you've got some complicated  
internal DNS domains on the servers you are managing. You can still do  
that via LWRPs but then you need to call that LWRP in every single role  
that you have which is going to be more complicated than just having a  
base role that manages /etc/resolv.conf and then exposes attributes to  
override. I'd probably use attributes in that case, and it makes it  
naturally searchable and that distinction is something that I'd probably  
like to search on and see in the node data.

So instead of using attributes for everything, start with LWRPs, and  
then use attributes when their properties are actually desired.

Sean O'Meara has been giving talks about this, he'll be talking about it  
at ChefConf, I think there's blog posts and slides up on the web  
somewhere but I'm not sure where...

On 3/20/15 9:24 AM, Hajducko, Steven wrote:

> So I read over the httpd and mysql and saw what you meant about using LWRP's in lieu of attributes.
> 
> My question is - when's the right time to do this and when does it make sense to use normal cookbooks with attributes?
> 
> In my case, the cobbler cookbook is exposing LWRP's for some parts of it's configuration ( distros, profiles, etc ). Anything that you can have many of.
> 
> However, when you have a singleton service ( ie - the actual 'cobbler' server ), does it make sense to shove it into an LWRP or just stay with the the normal include\_recipe and some configuration attributes? Is there somewhere that I missed that using attributes for configuration driven recipes is a bad idea?
> 
> --  
> sh
> 
> * * *
> 
> From: Lamont Granquist [lamont@chef.io](mailto:lamont@chef.io)  
> Sent: Friday, March 20, 2015 9:20 AM  
> To: [chef@lists.opscode.com](mailto:chef@lists.opscode.com)  
> Cc: Hajducko, Steven; Torben Knerr  
> Subject: Re: [chef] Re: Re: Exposing attributes from cookbooks you depend on
> 
> That's ideal philosophically, but is probably going to produce bad chef  
> code. One you've hit the computed attributes issue and worked around it  
> by moving setting attributes in recipes and exposed yourself to  
> compile/converge issues and started down the path of probably needing to  
> use 'lazy' attributes, then I'd rethink the idea of re-namespacing the  
> attributes.
> 
> On 3/20/15 2:09 AM, Torben Knerr wrote:
> 
> > My preference on this is to re-namespace the attributes the user is  
> > expected to set. I think of it as the "public interface" of a wrapper  
> > cookbook that is tested and also documented in the README.
> > 
> > Cheers, Torben
> > 
> > On Thu, Mar 19, 2015 at 11:07 PM, Lamont Granquist [lamont@chef.io](mailto:lamont@chef.io) wrote:
> > 
> > > On 3/19/15 1:53 PM, Hajducko, Steven wrote:
> > > 
> > > 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"]
> > > 
> > > yeah, don't set that attribute in the recipe.
> > > 
> > > you probably set it in the recipe because you hit the interpolated  
> > > attributes problem in the attributes file.
> > > 
> > > its better to just use default["cobbler"]["dhcp"]["gateway"] in the  
> > > attributes file of the proserv cookbook.

---

<div class="post-metadata">

**Author:** ![Michael\_D\_Mosier](https://avatars.discourse-cdn.com/v4/letter/m/43a26b/32.png) [@Michael\_D\_Mosier](https://discourse.chef.io/u/Michael_D_Mosier)\
**Post date:** [March 20, 2015, 5:50pm UTC](https://discourse.chef.io/t/exposing-attributes-from-cookbooks-you-depend-on/6429/9 "2015-03-20T17:50:30Z")

</div>

What is a good rule of thumb for naming roles, cookbooks, recipes. etc.  
I noticed we have two recipes both named amanda\_installer.rb one for mac  
and the other is for RHEL. That doesn’t sound like that’s right.  
Shouldn’t we name things by the os or something so you can tell what it  
is or is the point to make everything super generic?

Have a great weekend.

Cheers.

Michael D. Mosier  
Systems Guy  
University Of Texas  
Astro Physics

---

<div class="post-metadata">

**Author:** ![Kent\_Perrier](https://avatars.discourse-cdn.com/v4/letter/k/f475e1/32.png) [@Kent\_Perrier](https://discourse.chef.io/u/Kent_Perrier)\
**Post date:** [March 20, 2015, 6:12pm UTC](https://discourse.chef.io/t/exposing-attributes-from-cookbooks-you-depend-on/6429/10 "2015-03-20T18:12:48Z")

</div>

In that case, I'd have one cookbook and can do both operating systems.

Kent

On Fri, Mar 20, 2015 at 12:50 PM, michael david mosier \<  
mdm4435@astro.as.utexas.edu\> wrote:

> What is a good rule of thumb for naming roles, cookbooks, recipes. etc. I  
> noticed we have two recipes both named amanda\_installer.rb one for mac and  
> the other is for RHEL. That doesn't sound like that's right. Shouldn't we  
> name things by the os or something so you can tell what it is or is the  
> point to make everything super generic?
> 
> Have a great weekend.
> 
> Cheers.
> 
> Michael D. Mosier  
> Systems Guy  
> University Of Texas  
> Astro Physics

---

<div class="post-metadata">

**Author:** ![Shubby](https://avatars.discourse-cdn.com/v4/letter/s/f9ae1b/32.png) [@Shubby](https://discourse.chef.io/u/Shubby)\
**Post date:** [March 20, 2015, 6:12pm UTC](https://discourse.chef.io/t/exposing-attributes-from-cookbooks-you-depend-on/6429/11 "2015-03-20T18:12:32Z")

</div>

Chef doesn't force you to do this kind of thing one way or another. You  
should aim to write recipes that can be applied to as many systems as  
possible, and the way Chef is designed can help a lot with that, but it's  
not always possible. Certainly the differences between OSX and RHEL can  
warrant having separate recipes, even just for the sake of clarity.  
You could just have a single recipe that does something like this (and this  
isn't real code obviously):

case 'os'  
when 'osx'  
do a and b  
when 'rhel'  
do c and d  
end

do more things that work regardless of the OS

Or you can do something like this in the default recipe:

do foo # this works regardless of the OS  
do bar # and so does this

include\_recipe "mycookbook::#{node['os']}"

and have a recipe for each OS type you wish your cookbook to support.

[https://github.com/L2G/timezone-ii/blob/master/recipes/default.rb](https://github.com/L2G/timezone-ii/blob/master/recipes/default.rb) is an  
example of the latter.

On Fri, Mar 20, 2015 at 1:50 PM, michael david mosier \<  
mdm4435@astro.as.utexas.edu\> wrote:

> What is a good rule of thumb for naming roles, cookbooks, recipes. etc. I  
> noticed we have two recipes both named amanda\_installer.rb one for mac and  
> the other is for RHEL. That doesn't sound like that's right. Shouldn't we  
> name things by the os or something so you can tell what it is or is the  
> point to make everything super generic?
> 
> Have a great weekend.
> 
> Cheers.
> 
> Michael D. Mosier  
> Systems Guy  
> University Of Texas  
> Astro Physics

---

<div class="post-metadata">

**Author:** ![Ranjib](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/ranjib/32/1040_2.png) [@Ranjib](https://discourse.chef.io/u/Ranjib)\
**Post date:** [March 20, 2015, 7:46pm UTC](https://discourse.chef.io/t/exposing-attributes-from-cookbooks-you-depend-on/6429/12 "2015-03-20T19:46:16Z")

</div>

i prefer to name cookbooks as actual program/deamon/software they are  
running. like mysql, haproxy, nginx, etc. All top level node assignments  
are via roles, and role names indicate the key component (like mysql,  
nginx, etc) + customizations or ops requirement on top of it (like nrpe  
agent, logstash etc), generally these ops requirements are modeled as base  
role, and top level roles become base + recipe . For services (i.e. your  
own code), roles and recipes reflect the same pattern. Some time a  
service/role is consolidation of base + recipe[Y] + recipe[Z]. Usage of  
environments really depends on how many chef server you use, whether its  
chef 11 server or 12 server etc. depending upon these you can either use  
environment as prod/test/dev etc (if you share one chef server across  
environemnt) or use them service specific cluster (e.g. prod-x , prod-Y,  
prod-geren-X, prod-blue-Y in prod chef server, while test-x, test-y,  
test-green-x etc in test chef server).

Since all these are convention based (as in chef dont enforce these  
things), you get to choose how you want to model it. If the volume of code  
thats different from RHEL to OSX is high enough, and their dependencies are  
also very different, it makes lot of sense to keep them in different  
cookbooks. If not you can choose to make them sub recipes inside a single  
cookbook.

regards  
ranjib

On Fri, Mar 20, 2015 at 10:50 AM, michael david mosier \<  
mdm4435@astro.as.utexas.edu\> wrote:

> What is a good rule of thumb for naming roles, cookbooks, recipes. etc. I  
> noticed we have two recipes both named amanda\_installer.rb one for mac and  
> the other is for RHEL. That doesn't sound like that's right. Shouldn't we  
> name things by the os or something so you can tell what it is or is the  
> point to make everything super generic?
> 
> Have a great weekend.
> 
> Cheers.
> 
> Michael D. Mosier  
> Systems Guy  
> University Of Texas  
> Astro Physics

---

<div class="post-metadata">

**Author:** ![jdunn](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/jdunn/32/1800_2.png) [@jdunn](https://discourse.chef.io/u/jdunn)\
**Post date:** [March 20, 2015, 8:07pm UTC](https://discourse.chef.io/t/exposing-attributes-from-cookbooks-you-depend-on/6429/13 "2015-03-20T20:07:34Z")

</div>

On Fri, Mar 20, 2015 at 12:53 PM, Lamont Granquist [lamont@chef.io](mailto:lamont@chef.io) wrote:

> Sean O'Meara has been giving talks about this, he'll be talking about it at  
> ChefConf, I think there's blog posts and slides up on the web somewhere but  
> I'm not sure where...

Sean's slides on this topic are here.

> **[Configuration Management Camp 2015](https://www.slideshare.net/someara/cfgmgntcamp-2015)**
>
> Configuration Management Camp 2015 - Download as a PDF or view online for free

- Julian

---

<div class="post-metadata">

**Author:** ![tknerr](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/tknerr/32/21_2.png) [@tknerr](https://discourse.chef.io/u/tknerr)\
**Post date:** [March 21, 2015, 1:58pm UTC](https://discourse.chef.io/t/exposing-attributes-from-cookbooks-you-depend-on/6429/14 "2015-03-21T13:58:05Z")

</div>

@Lamont, thanks for the reminder. So far I'm setting attributes in  
recipes (=\> computed attributes) but have not come to lazy attributes  
yet. Must have been lucky 😉

That slide deck from Sean O'Meara is both beautiful and super relevant!

Chef should set out a bounty for each supermarket cookbook that is  
converted to a LWRP library cookbook by the community. I wish all  
cookbooks were like the httpd one already... 🙂

On Fri, Mar 20, 2015 at 9:07 PM, Julian C. Dunn [jdunn@aquezada.com](mailto:jdunn@aquezada.com) wrote:

> On Fri, Mar 20, 2015 at 12:53 PM, Lamont Granquist [lamont@chef.io](mailto:lamont@chef.io) wrote:
> 
> > Sean O'Meara has been giving talks about this, he'll be talking about it at  
> > ChefConf, I think there's blog posts and slides up on the web somewhere but  
> > I'm not sure where...
> 
> Sean's slides on this topic are here.  
> [Configuration Management Camp 2015 | PPT](http://www.slideshare.net/someara/cfgmgntcamp-2015)
> 
> - Julian

---

<div class="post-metadata">

**Author:** ![tknerr](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/tknerr/32/21_2.png) [@tknerr](https://discourse.chef.io/u/tknerr)\
**Post date:** [March 21, 2015, 2:37pm UTC](https://discourse.chef.io/t/exposing-attributes-from-cookbooks-you-depend-on/6429/15 "2015-03-21T14:37:15Z")

</div>

...and I guess using poise [0] is one of the easiest ways of writing  
reusable resources these days?

[0] [GitHub - poise/poise: A set of libraries for writing reusable Chef cookbooks](https://github.com/poise/poise)

On Sat, Mar 21, 2015 at 2:58 PM, Torben Knerr [mail@tknerr.de](mailto:mail@tknerr.de) wrote:

> @Lamont, thanks for the reminder. So far I'm setting attributes in  
> recipes (=\> computed attributes) but have not come to lazy attributes  
> yet. Must have been lucky 😉
> 
> That slide deck from Sean O'Meara is both beautiful and super relevant!
> 
> Chef should set out a bounty for each supermarket cookbook that is  
> converted to a LWRP library cookbook by the community. I wish all  
> cookbooks were like the httpd one already... 🙂
> 
> On Fri, Mar 20, 2015 at 9:07 PM, Julian C. Dunn [jdunn@aquezada.com](mailto:jdunn@aquezada.com) wrote:
> 
> > On Fri, Mar 20, 2015 at 12:53 PM, Lamont Granquist [lamont@chef.io](mailto:lamont@chef.io) wrote:
> > 
> > > Sean O'Meara has been giving talks about this, he'll be talking about it at  
> > > ChefConf, I think there's blog posts and slides up on the web somewhere but  
> > > I'm not sure where...
> > 
> > Sean's slides on this topic are here.  
> > [Configuration Management Camp 2015 | PPT](http://www.slideshare.net/someara/cfgmgntcamp-2015)
> > 
> > - Julian

---

<div class="post-metadata">

**Author:** ![tknerr](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/tknerr/32/21_2.png) [@tknerr](https://discourse.chef.io/u/tknerr)\
**Post date:** [March 21, 2015, 2:47pm UTC](https://discourse.chef.io/t/exposing-attributes-from-cookbooks-you-depend-on/6429/16 "2015-03-21T14:47:48Z")

</div>

...oh, and [GitHub - chef-boneyard/resource: DEPRECATED: Easier, More Powerful Chef Resources](https://github.com/chef-cookbooks/resource) from jkeiser  
looks pretty neat as well!

On Sat, Mar 21, 2015 at 3:37 PM, Torben Knerr [mail@tknerr.de](mailto:mail@tknerr.de) wrote:

> ...and I guess using poise [0] is one of the easiest ways of writing  
> reusable resources these days?
> 
> [0] [GitHub - poise/poise: A set of libraries for writing reusable Chef cookbooks](https://github.com/poise/poise)
> 
> On Sat, Mar 21, 2015 at 2:58 PM, Torben Knerr [mail@tknerr.de](mailto:mail@tknerr.de) wrote:
> 
> > @Lamont, thanks for the reminder. So far I'm setting attributes in  
> > recipes (=\> computed attributes) but have not come to lazy attributes  
> > yet. Must have been lucky 😉
> > 
> > That slide deck from Sean O'Meara is both beautiful and super relevant!
> > 
> > Chef should set out a bounty for each supermarket cookbook that is  
> > converted to a LWRP library cookbook by the community. I wish all  
> > cookbooks were like the httpd one already... 🙂
> > 
> > On Fri, Mar 20, 2015 at 9:07 PM, Julian C. Dunn [jdunn@aquezada.com](mailto:jdunn@aquezada.com) wrote:
> > 
> > > On Fri, Mar 20, 2015 at 12:53 PM, Lamont Granquist [lamont@chef.io](mailto:lamont@chef.io) wrote:
> > > 
> > > > Sean O'Meara has been giving talks about this, he'll be talking about it at  
> > > > ChefConf, I think there's blog posts and slides up on the web somewhere but  
> > > > I'm not sure where...
> > > 
> > > Sean's slides on this topic are here.  
> > > [Configuration Management Camp 2015 | PPT](http://www.slideshare.net/someara/cfgmgntcamp-2015)
> > > 
> > > - Julian

---

<div class="post-metadata">

**Author:** ![Michael\_D\_Mosier](https://avatars.discourse-cdn.com/v4/letter/m/43a26b/32.png) [@Michael\_D\_Mosier](https://discourse.chef.io/u/Michael_D_Mosier)\
**Post date:** [March 23, 2015, 11:43am UTC](https://discourse.chef.io/t/exposing-attributes-from-cookbooks-you-depend-on/6429/17 "2015-03-23T11:43:03Z")

</div>

Thank you everyone for helping me with naming conventions.

I have another question. Again I am fairly new to this so I may have  
just not learned how this works yet.

If someone has 1000 nodes. Going to each machine and running chef-client  
doesn’t feel like it’s the best way to do things. I know on the  
enterprise side they have a push type plugin. I also know with knife I  
can force a push to all the nodes. The problem I see with this is you  
may need to write an error handler into a recipe so you will know that  
something that was just updated on the node errored out. If your on each  
machine you can see on the screen if it errored out when you run  
chef-client but remotely I am not sure how to handle catching errors. I  
was thinking since there are two built in error handlers maybe I could  
write a script that would email me whenever an error occurs but that may  
mean that each node has to have send-mail running.

1. How do you all deal with updating multiple nodes without SSHing to  
each and running chef-client

2. How do you all deal with error handling.

Thank yo so much

Michael D. Mosier  
Systems Guy  
University Of Texas  
Astro Physics

---

<div class="post-metadata">

**Author:** ![Tensibai](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/tensibai/32/29_2.png) [@Tensibai](https://discourse.chef.io/u/Tensibai)\
**Post date:** [March 23, 2015, 1:16pm UTC](https://discourse.chef.io/t/exposing-attributes-from-cookbooks-you-depend-on/6429/18 "2015-03-23T13:16:46Z")

</div>

For my personnal use case (and there's others) I'm using rundeck to  
launch chef on nodes (one solution on many).

If a run ends in error it's marked as failed and I can relaunch on  
failed nodes easily.

I do use rundeck for specific 'need now' run, for the rest I rely on a  
crontab job launching chef with a report/error handler which report back  
to a dashboard the updated resources, and some other specific needs  
(attributes accessed in our namespace, GAV of artifact deployed from  
nexus on this machine, cookbook version used, etc.)

I do keep hope we can open source it on github one day.

There's a lot of way to do this, which one is the good for you depends a  
lot of your interest of a run result and how you want to act on failure.

My 2 cents on this subject, hope it will help.

Le 2015-03-23 12:43, michael david mosier a écrit :

> Thank you everyone for helping me with naming conventions.
> 
> I have another question. Again I am fairly new to this so I may have just not learned how this works yet.
> 
> If someone has 1000 nodes. Going to each machine and running chef-client doesn't feel like it's the best way to do things. I know on the enterprise side they have a push type plugin. I also know with knife I can force a push to all the nodes. The problem I see with this is you may need to write an error handler into a recipe so you will know that something that was just updated on the node errored out. If your on each machine you can see on the screen if it errored out when you run chef-client but remotely I am not sure how to handle catching errors. I was thinking since there are two built in error handlers maybe I could write a script that would email me whenever an error occurs but that may mean that each node has to have send-mail running.
> 
> 1. How do you all deal with updating multiple nodes without SSHing to each and running chef-client
> 
> 2. How do you all deal with error handling.
> 
> Thank yo so much
> 
> Michael D. Mosier  
> Systems Guy  
> University Of Texas  
> Astro Physics

---

<div class="post-metadata">

**Author:** ![Mike](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/mike/32/18_2.png) [@Mike](https://discourse.chef.io/u/Mike)\
**Post date:** [March 23, 2015, 3:45pm UTC](https://discourse.chef.io/t/exposing-attributes-from-cookbooks-you-depend-on/6429/19 "2015-03-23T15:45:50Z")

</div>

Hi Michael!

In our environments, we run Chef as a daemon, and it executes every 30  
minutes (or so, depending on splay).

We use the chef-handler-datadog plugin [1](https://supermarket.chef.io/tools/chef-handler-datadog) (I work at Datadog, so that  
seemed likely), which will report the status to Chef Runs in a nice,  
aggregated manner [2](http://cl.ly/image/451Z2i0E0n0N).

Best,  
-M

On Mon, Mar 23, 2015 at 7:43 AM, michael david mosier \<  
mdm4435@astro.as.utexas.edu\> wrote:

> Thank you everyone for helping me with naming conventions.
> 
> I have another question. Again I am fairly new to this so I may have just  
> not learned how this works yet.
> 
> If someone has 1000 nodes. Going to each machine and running chef-client  
> doesn't feel like it's the best way to do things. I know on the enterprise  
> side they have a push type plugin. I also know with knife I can force a  
> push to all the nodes. The problem I see with this is you may need to write  
> an error handler into a recipe so you will know that something that was  
> just updated on the node errored out. If your on each machine you can see  
> on the screen if it errored out when you run chef-client but remotely I am  
> not sure how to handle catching errors. I was thinking since there are two  
> built in error handlers maybe I could write a script that would email me  
> whenever an error occurs but that may mean that each node has to have  
> send-mail running.
> 
> 1. How do you all deal with updating multiple nodes without SSHing to each  
> and running chef-client
> 
> 2. How do you all deal with error handling.
> 
> Thank yo so much
> 
> Michael D. Mosier  
> Systems Guy  
> University Of Texas  
> Astro Physics

---

<div class="post-metadata">

**Author:** ![Ranjib](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/ranjib/32/1040_2.png) [@Ranjib](https://discourse.chef.io/u/Ranjib)\
**Post date:** [March 23, 2015, 10:48pm UTC](https://discourse.chef.io/t/exposing-attributes-from-cookbooks-you-depend-on/6429/20 "2015-03-23T22:48:45Z")

</div>

we use hipchat for immediate notification when chef run fails. and the dd  
plugins, to create fine grained alerts.

we have written blender to automate the push/coordination needs, for on  
demand we use the ssh driver , and for periodic fleetwide run we use serf  
backend (scales way better than ssh),

I'll recommend to use the hipchat or dd or any other error handler  
irrespective of the push workflow bit,

[0][https://help.hipchat.com/knowledgebase/articles/65276-chef-integration](https://help.hipchat.com/knowledgebase/articles/65276-chef-integration)  
[1][GitHub - PagerDuty/blender: A modular orchestration engine](https://github.com/PagerDuty/blender)  
[2][GitHub - PagerDuty/blender-chef: Chef search based host discovery for blender.](https://github.com/PagerDuty/blender-chef)

On Mon, Mar 23, 2015 at 4:43 AM, michael david mosier \<  
mdm4435@astro.as.utexas.edu\> wrote:

> Thank you everyone for helping me with naming conventions.
> 
> I have another question. Again I am fairly new to this so I may have just  
> not learned how this works yet.
> 
> If someone has 1000 nodes. Going to each machine and running chef-client  
> doesn't feel like it's the best way to do things. I know on the enterprise  
> side they have a push type plugin. I also know with knife I can force a  
> push to all the nodes. The problem I see with this is you may need to write  
> an error handler into a recipe so you will know that something that was  
> just updated on the node errored out. If your on each machine you can see  
> on the screen if it errored out when you run chef-client but remotely I am  
> not sure how to handle catching errors. I was thinking since there are two  
> built in error handlers maybe I could write a script that would email me  
> whenever an error occurs but that may mean that each node has to have  
> send-mail running.
> 
> 1. How do you all deal with updating multiple nodes without SSHing to each  
> and running chef-client
> 
> 2. How do you all deal with error handling.
> 
> Thank yo so much
> 
> Michael D. Mosier  
> Systems Guy  
> University Of Texas  
> Astro Physics