# Roles and Versioning

**URL:** <https://discourse.chef.io/t/roles-and-versioning/3321>\
**Category:** Chef Infra (archive)\
**Created:** [November 20, 2012, 6:31pm UTC](https://discourse.chef.io/t/roles-and-versioning/3321 "2012-11-20T18:31:49Z")\
**Posts on this page:** 16\
**Page:** 1

<div class="post-metadata">

**Author:** ![Kevin\_Christen](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/kevin_christen/32/479_2.png) [@Kevin\_Christen](https://discourse.chef.io/u/Kevin_Christen)\
**Post date:** [November 20, 2012, 6:31pm UTC](https://discourse.chef.io/t/roles-and-versioning/3321/1 "2012-11-20T18:31:49Z")

</div>

Here’s a scenario for the use of roles and cookbooks in Chef server that  
confuses me. I’d like to know how the community handles this situation.  
Imagine that I have a cookbook “foo” at version 1.0.0 with a single recipe  
"bar". I define a role “foo\_host” with “recipe[foo::bar]” in its run\_list.

Now imagine that I improve the “foo” cookbook by adding a “baz” recipe and  
increment it’s version number to 1.1.0. What do I do with the role? If I  
add the new recipe to the “foo\_host” run\_list, I will break any nodes that  
won’t use the latest version of the cookbook because of an environment  
version constraint. I can only think of a few solutions:

- Version the role through its name. In other words, leave "foo\_host"  
alone and create a “foo\_host\_1” role with both recipes in its run\_list.
- Run separate versions of chef server for each environment, as  
mentioned here[http://wiki.opscode.com/display/chef/Infrastructure+Proposal](http://wiki.opscode.com/display/chef/Infrastructure+Proposal).  
Update the role in only those servers who’s environment will pick up the  
latest version of the cookbook.
- Don’t use a role for this purpose. Instead, define a separate,  
versioned “wrapper” cookbook as described by Bryan Berry  
here[http://devopsanywhere.blogspot.it/2012/11/how-to-write-reusable-chef-cookbooks.html](http://devopsanywhere.blogspot.it/2012/11/how-to-write-reusable-chef-cookbooks.html)  
.

Is there a community consensus on how to deal with this situation?

Thanks,  
Kevin Christen

---

<div class="post-metadata">

**Author:** ![Jay\_Feldblum](https://avatars.discourse-cdn.com/v4/letter/j/9fc29f/32.png) [@Jay\_Feldblum](https://discourse.chef.io/u/Jay_Feldblum)\
**Post date:** [November 20, 2012, 6:47pm UTC](https://discourse.chef.io/t/roles-and-versioning/3321/2 "2012-11-20T18:47:29Z")

</div>

Kevin,

If you treat roles as implementation, then you will need to start  
versioning them.

If you treat roles as interface, as a declaration of intent only, and  
remove all implementation from them, then you will need to implement them  
with an implementation cookbook, so to speak. The role will not need to be  
versioned itself; only the implementation cookbook will need to be  
versioned.

Cheers,  
Jay

On Tue, Nov 20, 2012 at 1:31 PM, Kevin Christen [kevin.christen@gmail.com](mailto:kevin.christen@gmail.com)wrote:

> Here's a scenario for the use of roles and cookbooks in Chef server that  
> confuses me. I'd like to know how the community handles this situation.  
> Imagine that I have a cookbook "foo" at version 1.0.0 with a single recipe  
> "bar". I define a role "foo\_host" with "recipe[foo::bar]" in its run\_list.
> 
> Now imagine that I improve the "foo" cookbook by adding a "baz" recipe and  
> increment it's version number to 1.1.0. What do I do with the role? If I  
> add the new recipe to the "foo\_host" run\_list, I will break any nodes that  
> won't use the latest version of the cookbook because of an environment  
> version constraint. I can only think of a few solutions:
> 
> - Version the role through its name. In other words, leave "foo\_host"  
> alone and create a "foo\_host\_1" role with both recipes in its run\_list.
> - Run separate versions of chef server for each environment, as  
> mentioned here[http://wiki.opscode.com/display/chef/Infrastructure+Proposal](http://wiki.opscode.com/display/chef/Infrastructure+Proposal).  
> Update the role in only those servers who's environment will pick up the  
> latest version of the cookbook.
> - Don't use a role for this purpose. Instead, define a separate,  
> versioned "wrapper" cookbook as described by Bryan Berry here[http://devopsanywhere.blogspot.it/2012/11/how-to-write-reusable-chef-cookbooks.html](http://devopsanywhere.blogspot.it/2012/11/how-to-write-reusable-chef-cookbooks.html)  
> .
> 
> Is there a community consensus on how to deal with this situation?
> 
> Thanks,  
> Kevin Christen

---

<div class="post-metadata">

**Author:** ![realityforge](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/realityforge/32/395_2.png) [@realityforge](https://discourse.chef.io/u/realityforge)\
**Post date:** [November 20, 2012, 7:05pm UTC](https://discourse.chef.io/t/roles-and-versioning/3321/3 "2012-11-20T19:05:56Z")

</div>

On Wed, Nov 21, 2012 at 5:31 AM, Kevin Christen [kevin.christen@gmail.com](mailto:kevin.christen@gmail.com)wrote:

> - Version the role through its name. In other words, leave "foo\_host"  
> alone and create a "foo\_host\_1" role with both recipes in its run\_list.
> - Run separate versions of chef server for each environment, as  
> mentioned here[http://wiki.opscode.com/display/chef/Infrastructure+Proposal](http://wiki.opscode.com/display/chef/Infrastructure+Proposal).  
> Update the role in only those servers who's environment will pick up the  
> latest version of the cookbook.
> - Don't use a role for this purpose. Instead, define a separate,  
> versioned "wrapper" cookbook as described by Bryan Berry here[http://devopsanywhere.blogspot.it/2012/11/how-to-write-reusable-chef-cookbooks.html](http://devopsanywhere.blogspot.it/2012/11/how-to-write-reusable-chef-cookbooks.html)  
> .
> 
> Is there a community consensus on how to deal with this situation?

We have used the first option and the last option. The first is painful and  
ugly to use and easy to get things wrong as you are constantly swapping  
nodes from one role to the next and if you get something wrong you can have  
the same node with two versions of a single logical role. The last option  
works well for us (Although we differentiate between role and wrapper  
cookbooks [1]). The middle option works ok if you do not have cross talk  
between environments and don't use it as a CMDB. However if you want to  
version attribute data as well as run list data I would suggest that the  
second option still needs to be combined with the third option to simplify  
understanding of the system.

## [1] [Role Cookbooks and Wrapper Cookbooks](http://realityforge.org/code/2012/11/19/role-cookbooks-and-wrapper-cookbooks.html)

Cheers,

Peter Donald

---

<div class="post-metadata">

**Author:** ![Bryan\_Berry](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/bryan_berry/32/213_2.png) [@Bryan\_Berry](https://discourse.chef.io/u/Bryan_Berry)\
**Post date:** [November 20, 2012, 7:08pm UTC](https://discourse.chef.io/t/roles-and-versioning/3321/4 "2012-11-20T19:08:43Z")

</div>

hey Kevin,

I recommend reading Adam Jacob's comments on my "Gangnam Style" post.

In his argument for roles he essentially says that roles should be used as  
aliases to a run\_list and do your best to keep data out of them. I can live  
w/ that use of roles, because they are friendlier to search for.

Call me crazy but I think we are rapidly approaching consensus that you  
should use generic cookbooks for the generic part of your configuration -  
whether or not u ever open-source them - and put the data and tweaks that  
drive the generic cookbook in an application cookbook. That said, this  
consensus may only exist in my head 🙂

My advice, listen closely to whatever Peter Donald and Jamie Winsor say or  
write

On Tue, Nov 20, 2012 at 7:31 PM, Kevin Christen [kevin.christen@gmail.com](mailto:kevin.christen@gmail.com)wrote:

> Here's a scenario for the use of roles and cookbooks in Chef server that  
> confuses me. I'd like to know how the community handles this situation.  
> Imagine that I have a cookbook "foo" at version 1.0.0 with a single recipe  
> "bar". I define a role "foo\_host" with "recipe[foo::bar]" in its run\_list.
> 
> Now imagine that I improve the "foo" cookbook by adding a "baz" recipe and  
> increment it's version number to 1.1.0. What do I do with the role? If I  
> add the new recipe to the "foo\_host" run\_list, I will break any nodes that  
> won't use the latest version of the cookbook because of an environment  
> version constraint. I can only think of a few solutions:
> 
> - Version the role through its name. In other words, leave "foo\_host"  
> alone and create a "foo\_host\_1" role with both recipes in its run\_list.
> - Run separate versions of chef server for each environment, as  
> mentioned here[http://wiki.opscode.com/display/chef/Infrastructure+Proposal](http://wiki.opscode.com/display/chef/Infrastructure+Proposal).  
> Update the role in only those servers who's environment will pick up the  
> latest version of the cookbook.
> - Don't use a role for this purpose. Instead, define a separate,  
> versioned "wrapper" cookbook as described by Bryan Berry here[http://devopsanywhere.blogspot.it/2012/11/how-to-write-reusable-chef-cookbooks.html](http://devopsanywhere.blogspot.it/2012/11/how-to-write-reusable-chef-cookbooks.html)  
> .
> 
> Is there a community consensus on how to deal with this situation?
> 
> Thanks,  
> Kevin Christen

---

<div class="post-metadata">

**Author:** ![Torben\_Knerr](https://avatars.discourse-cdn.com/v4/letter/t/ba8739/32.png) [@Torben\_Knerr](https://discourse.chef.io/u/Torben_Knerr)\
**Post date:** [November 20, 2012, 7:39pm UTC](https://discourse.chef.io/t/roles-and-versioning/3321/5 "2012-11-20T19:39:02Z")

</div>

Am 20.11.2012 20:09 schrieb "Bryan Berry" [bryan.berry@gmail.com](mailto:bryan.berry@gmail.com):

> hey Kevin,
> 
> I recommend reading Adam Jacob's comments on my "Gangnam Style" post.
> 
> In his argument for roles he essentially says that roles should be used  
> as aliases to a run\_list and do your best to keep data out of them. I can  
> live w/ that use of roles, because they are friendlier to search for.
> 
> Call me crazy but I think we are rapidly approaching consensus that you  
> should use generic cookbooks for the generic part of your configuration -  
> whether or not u ever open-source them - and put the data and tweaks that  
> drive the generic cookbook in an application cookbook. That said, this  
> consensus may only exist in my head 🙂

I'm in and also have the feeling that this more and more becomes community  
consensus. It feels like the right way...

> My advice, listen closely to whatever Peter Donald and Jamie Winsor say  
> or write
> 
> On Tue, Nov 20, 2012 at 7:31 PM, Kevin Christen [kevin.christen@gmail.com](mailto:kevin.christen@gmail.com)  
> wrote:
> 
> > Here's a scenario for the use of roles and cookbooks in Chef server that  
> > confuses me. I'd like to know how the community handles this situation.  
> > Imagine that I have a cookbook "foo" at version 1.0.0 with a single recipe  
> > "bar". I define a role "foo\_host" with "recipe[foo::bar]" in its run\_list.
> > 
> > Now imagine that I improve the "foo" cookbook by adding a "baz" recipe  
> > and increment it's version number to 1.1.0. What do I do with the role? If  
> > I add the new recipe to the "foo\_host" run\_list, I will break any nodes  
> > that won't use the latest version of the cookbook because of an environment  
> > version constraint. I can only think of a few solutions:
> > 
> > Version the role through its name. In other words, leave "foo\_host"  
> > alone and create a "foo\_host\_1" role with both recipes in its run\_list.  
> > Run separate versions of chef server for each environment, as  
> > mentioned here. Update the role in only those servers who's environment  
> > will pick up the latest version of the cookbook.  
> > Don't use a role for this purpose. Instead, define a separate, versioned  
> > "wrapper" cookbook as described by Bryan Berry here.  
> > Is there a community consensus on how to deal with this situation?
> > 
> > Thanks,  
> > Kevin Christen

---

<div class="post-metadata">

**Author:** ![Torben\_Knerr](https://avatars.discourse-cdn.com/v4/letter/t/ba8739/32.png) [@Torben\_Knerr](https://discourse.chef.io/u/Torben_Knerr)\
**Post date:** [November 20, 2012, 7:47pm UTC](https://discourse.chef.io/t/roles-and-versioning/3321/6 "2012-11-20T19:47:00Z")

</div>

Am 20.11.2012 20:09 schrieb "Bryan Berry" [bryan.berry@gmail.com](mailto:bryan.berry@gmail.com):

> hey Kevin,
> 
> I recommend reading Adam Jacob's comments on my "Gangnam Style" post.
> 
> In his argument for roles he essentially says that roles should be used  
> as aliases to a run\_list and do your best to keep data out of them. I can  
> live w/ that use of roles, because they are friendlier to search for.
> 
> Call me crazy but I think we are rapidly approaching consensus that you  
> should use generic cookbooks for the generic part of your configuration -  
> whether or not u ever open-source them - and put the data and tweaks that  
> drive the generic cookbook in an application cookbook. That said, this  
> consensus may only exist in my head 🙂
> 
> My advice, listen closely to whatever Peter Donald and Jamie Winsor say  
> or write

...and I totally second that. Hats up! 🙂

> On Tue, Nov 20, 2012 at 7:31 PM, Kevin Christen [kevin.christen@gmail.com](mailto:kevin.christen@gmail.com)  
> wrote:
> 
> > Here's a scenario for the use of roles and cookbooks in Chef server that  
> > confuses me. I'd like to know how the community handles this situation.  
> > Imagine that I have a cookbook "foo" at version 1.0.0 with a single recipe  
> > "bar". I define a role "foo\_host" with "recipe[foo::bar]" in its run\_list.
> > 
> > Now imagine that I improve the "foo" cookbook by adding a "baz" recipe  
> > and increment it's version number to 1.1.0. What do I do with the role? If  
> > I add the new recipe to the "foo\_host" run\_list, I will break any nodes  
> > that won't use the latest version of the cookbook because of an environment  
> > version constraint. I can only think of a few solutions:
> > 
> > Version the role through its name. In other words, leave "foo\_host"  
> > alone and create a "foo\_host\_1" role with both recipes in its run\_list.  
> > Run separate versions of chef server for each environment, as  
> > mentioned here. Update the role in only those servers who's environment  
> > will pick up the latest version of the cookbook.  
> > Don't use a role for this purpose. Instead, define a separate, versioned  
> > "wrapper" cookbook as described by Bryan Berry here.  
> > Is there a community consensus on how to deal with this situation?
> > 
> > Thanks,  
> > Kevin Christen

---

<div class="post-metadata">

**Author:** ![J\_Light](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/j_light/32/412_2.png) [@J\_Light](https://discourse.chef.io/u/J_Light)\
**Post date:** [November 20, 2012, 9:31pm UTC](https://discourse.chef.io/t/roles-and-versioning/3321/7 "2012-11-20T21:31:15Z")

</div>

So you are saying that you don't like the option of using any  
default\_attributes nor override\_attributes in roles?

Just trying to understand your proposed workflow as I find those options  
very useful.  
On Nov 20, 2012 2:47 PM, "Torben Knerr" [ukio@gmx.de](mailto:ukio@gmx.de) wrote:

> Am 20.11.2012 20:09 schrieb "Bryan Berry" [bryan.berry@gmail.com](mailto:bryan.berry@gmail.com):
> 
> > hey Kevin,
> > 
> > I recommend reading Adam Jacob's comments on my "Gangnam Style" post.
> > 
> > In his argument for roles he essentially says that roles should be used  
> > as aliases to a run\_list and do your best to keep data out of them. I can  
> > live w/ that use of roles, because they are friendlier to search for.
> > 
> > Call me crazy but I think we are rapidly approaching consensus that you  
> > should use generic cookbooks for the generic part of your configuration -  
> > whether or not u ever open-source them - and put the data and tweaks that  
> > drive the generic cookbook in an application cookbook. That said, this  
> > consensus may only exist in my head 🙂
> > 
> > My advice, listen closely to whatever Peter Donald and Jamie Winsor say  
> > or write
> 
> ...and I totally second that. Hats up! 🙂
> 
> > On Tue, Nov 20, 2012 at 7:31 PM, Kevin Christen \<  
> > [kevin.christen@gmail.com](mailto:kevin.christen@gmail.com)\> wrote:
> > 
> > > Here's a scenario for the use of roles and cookbooks in Chef server  
> > > that confuses me. I'd like to know how the community handles this  
> > > situation. Imagine that I have a cookbook "foo" at version 1.0.0 with a  
> > > single recipe "bar". I define a role "foo\_host" with "recipe[foo::bar]" in  
> > > its run\_list.
> > > 
> > > Now imagine that I improve the "foo" cookbook by adding a "baz" recipe  
> > > and increment it's version number to 1.1.0. What do I do with the role? If  
> > > I add the new recipe to the "foo\_host" run\_list, I will break any nodes  
> > > that won't use the latest version of the cookbook because of an environment  
> > > version constraint. I can only think of a few solutions:
> > > 
> > > Version the role through its name. In other words, leave "foo\_host"  
> > > alone and create a "foo\_host\_1" role with both recipes in its run\_list.  
> > > Run separate versions of chef server for each environment, as  
> > > mentioned here. Update the role in only those servers who's environment  
> > > will pick up the latest version of the cookbook.  
> > > Don't use a role for this purpose. Instead, define a separate,  
> > > versioned "wrapper" cookbook as described by Bryan Berry here.  
> > > Is there a community consensus on how to deal with this situation?
> > > 
> > > Thanks,  
> > > Kevin Christen

---

<div class="post-metadata">

**Author:** ![Kevin\_Christen](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/kevin_christen/32/479_2.png) [@Kevin\_Christen](https://discourse.chef.io/u/Kevin_Christen)\
**Post date:** [November 21, 2012, 3:25pm UTC](https://discourse.chef.io/t/roles-and-versioning/3321/8 "2012-11-21T15:25:56Z")

</div>

Jay,

Can you elaborate on what you mean by treating a role as interface? It  
seems to me that a run\_list is implementation. Or are you thinking that a  
run\_list containing other roles is an interface, while a run\_list  
containing recipes is an implementation?

Thanks,  
Kevin Christen

On Tue, Nov 20, 2012 at 12:47 PM, Jay Feldblum [y\_feldblum@yahoo.com](mailto:y_feldblum@yahoo.com) wrote:

> Kevin,
> 
> If you treat roles as implementation, then you will need to start  
> versioning them.
> 
> If you treat roles as interface, as a declaration of intent only, and  
> remove all implementation from them, then you will need to implement them  
> with an implementation cookbook, so to speak. The role will not need to be  
> versioned itself; only the implementation cookbook will need to be  
> versioned.
> 
> Cheers,  
> Jay
> 
> On Tue, Nov 20, 2012 at 1:31 PM, Kevin Christen [kevin.christen@gmail.com](mailto:kevin.christen@gmail.com)wrote:
> 
> > Here's a scenario for the use of roles and cookbooks in Chef server that  
> > confuses me. I'd like to know how the community handles this situation.  
> > Imagine that I have a cookbook "foo" at version 1.0.0 with a single recipe  
> > "bar". I define a role "foo\_host" with "recipe[foo::bar]" in its run\_list.
> > 
> > Now imagine that I improve the "foo" cookbook by adding a "baz" recipe  
> > and increment it's version number to 1.1.0. What do I do with the role? If  
> > I add the new recipe to the "foo\_host" run\_list, I will break any nodes  
> > that won't use the latest version of the cookbook because of an environment  
> > version constraint. I can only think of a few solutions:
> > 
> > - Version the role through its name. In other words, leave "foo\_host"  
> > alone and create a "foo\_host\_1" role with both recipes in its run\_list.
> > - Run separate versions of chef server for each environment, as  
> > mentioned here[http://wiki.opscode.com/display/chef/Infrastructure+Proposal](http://wiki.opscode.com/display/chef/Infrastructure+Proposal).  
> > Update the role in only those servers who's environment will pick up the  
> > latest version of the cookbook.
> > - Don't use a role for this purpose. Instead, define a separate,  
> > versioned "wrapper" cookbook as described by Bryan Berry here[http://devopsanywhere.blogspot.it/2012/11/how-to-write-reusable-chef-cookbooks.html](http://devopsanywhere.blogspot.it/2012/11/how-to-write-reusable-chef-cookbooks.html)  
> > .
> > 
> > Is there a community consensus on how to deal with this situation?
> > 
> > Thanks,  
> > Kevin Christen

---

<div class="post-metadata">

**Author:** ![Jay\_Feldblum](https://avatars.discourse-cdn.com/v4/letter/j/9fc29f/32.png) [@Jay\_Feldblum](https://discourse.chef.io/u/Jay_Feldblum)\
**Post date:** [November 21, 2012, 4:37pm UTC](https://discourse.chef.io/t/roles-and-versioning/3321/9 "2012-11-21T16:37:55Z")

</div>

Kevin,

The boundary between interface and implementation depends on the context or  
on the viewpoint, and we need to be able to discover where that boundary is  
in the various cases we actually end up dealing with.

For me, default and override attributes in a role seem generally to lie on  
the implementation side of that boundary. That much seems, in most cases,  
open-and-shut. But the content of the run-list is more of an open question  
to me, and I suppose that, at least for now, I would end up deciding that  
on a case-by-case basis.

Keep in mind that something might, from one viewpoint, be an interface but,  
from another viewpoint, be an implementation.

This is of course applicable to code-type roles (roles that you keep in  
git), and not applicable to data-type roles (roles that are not kept in  
git).

Cheers,  
Jay

On Wed, Nov 21, 2012 at 10:25 AM, Kevin Christen  
[kevin.christen@gmail.com](mailto:kevin.christen@gmail.com)wrote:

> Jay,
> 
> Can you elaborate on what you mean by treating a role as interface? It  
> seems to me that a run\_list is implementation. Or are you thinking that a  
> run\_list containing other roles is an interface, while a run\_list  
> containing recipes is an implementation?
> 
> Thanks,  
> Kevin Christen
> 
> On Tue, Nov 20, 2012 at 12:47 PM, Jay Feldblum [y\_feldblum@yahoo.com](mailto:y_feldblum@yahoo.com)wrote:
> 
> > Kevin,
> > 
> > If you treat roles as implementation, then you will need to start  
> > versioning them.
> > 
> > If you treat roles as interface, as a declaration of intent only, and  
> > remove all implementation from them, then you will need to implement them  
> > with an implementation cookbook, so to speak. The role will not need to be  
> > versioned itself; only the implementation cookbook will need to be  
> > versioned.
> > 
> > Cheers,  
> > Jay

---

<div class="post-metadata">

**Author:** ![Tim\_Smith](https://avatars.discourse-cdn.com/v4/letter/t/8dc957/32.png) [@Tim\_Smith](https://discourse.chef.io/u/Tim_Smith)\
**Post date:** [November 21, 2012, 5:50pm UTC](https://discourse.chef.io/t/roles-and-versioning/3321/10 "2012-11-21T17:50:40Z")

</div>

I understand the desire to keep roles simple and generic, but the lack of versioning in roles is a really huge pain point in working with Chef. I never add attributes to my roles to eliminate configuration from the roles, but there is often a need to change the run list portion of the roles. I use a single Chef server for my staging and production environments so I need to be able to test changes for a release before pushing those changes to prod. Right now if someone on my Dev team makes any modifications to the run list in a role I either have to push it to production immediately or undergo very manual renaming of roles / node changes. Versions would eliminate these problems entirely as I could use version 1 of a role in production while changing run lists entirely in a dev environment.

From: Jay Feldblum \<[y\_feldblum@yahoo.com](mailto:y_feldblum@yahoo.com)[mailto:y\_feldblum@yahoo.com](mailto:y_feldblum@yahoo.com)\>  
Reply-To: "chef@lists.opscode.com[mailto:chef@lists.opscode.com](mailto:chef@lists.opscode.com)" \<[chef@lists.opscode.com](mailto:chef@lists.opscode.com)[mailto:chef@lists.opscode.com](mailto:chef@lists.opscode.com)\>  
Date: Wednesday, November 21, 2012 8:37 AM  
To: "chef@lists.opscode.com[mailto:chef@lists.opscode.com](mailto:chef@lists.opscode.com)" \<[chef@lists.opscode.com](mailto:chef@lists.opscode.com)[mailto:chef@lists.opscode.com](mailto:chef@lists.opscode.com)\>  
Subject: [chef] Re: Re: Re: Roles and Versioning

Kevin,

The boundary between interface and implementation depends on the context or on the viewpoint, and we need to be able to discover where that boundary is in the various cases we actually end up dealing with.

For me, default and override attributes in a role seem generally to lie on the implementation side of that boundary. That much seems, in most cases, open-and-shut. But the content of the run-list is more of an open question to me, and I suppose that, at least for now, I would end up deciding that on a case-by-case basis.

Keep in mind that something might, from one viewpoint, be an interface but, from another viewpoint, be an implementation.

This is of course applicable to code-type roles (roles that you keep in git), and not applicable to data-type roles (roles that are not kept in git).

Cheers,  
Jay

On Wed, Nov 21, 2012 at 10:25 AM, Kevin Christen \<[kevin.christen@gmail.com](mailto:kevin.christen@gmail.com)[mailto:kevin.christen@gmail.com](mailto:kevin.christen@gmail.com)\> wrote:  
Jay,

Can you elaborate on what you mean by treating a role as interface? It seems to me that a run\_list is implementation. Or are you thinking that a run\_list containing other roles is an interface, while a run\_list containing recipes is an implementation?

Thanks,  
Kevin Christen

On Tue, Nov 20, 2012 at 12:47 PM, Jay Feldblum \<[y\_feldblum@yahoo.com](mailto:y_feldblum@yahoo.com)[mailto:y\_feldblum@yahoo.com](mailto:y_feldblum@yahoo.com)\> wrote:  
Kevin,

If you treat roles as implementation, then you will need to start versioning them.

If you treat roles as interface, as a declaration of intent only, and remove all implementation from them, then you will need to implement them with an implementation cookbook, so to speak. The role will not need to be versioned itself; only the implementation cookbook will need to be versioned.

Cheers,  
Jay

---

<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:** [November 21, 2012, 5:54pm UTC](https://discourse.chef.io/t/roles-and-versioning/3321/11 "2012-11-21T17:54:11Z")

</div>

Tim:  
For environments specific run lists, use Environment Run Lists.  
[http://wiki.opscode.com/display/chef/Environments#Environments-PerEnvironmentRunListsinRoles](http://wiki.opscode.com/display/chef/Environments#Environments-PerEnvironmentRunListsinRoles)

-M

On Wed, Nov 21, 2012 at 12:50 PM, Tim Smith [Tim.Smith@webtrends.com](mailto:Tim.Smith@webtrends.com) wrote:

> I understand the desire to keep roles simple and generic, but the lack of  
> versioning in roles is a really huge pain point in working with Chef. I  
> never add attributes to my roles to eliminate configuration from the roles,  
> but there is often a need to change the run list portion of the roles. I  
> use a single Chef server for my staging and production environments so I  
> need to be able to test changes for a release before pushing those changes  
> to prod. Right now if someone on my Dev team makes any modifications to the  
> run list in a role I either have to push it to production immediately or  
> undergo very manual renaming of roles / node changes. Versions would  
> eliminate these problems entirely as I could use version 1 of a role in  
> production while changing run lists entirely in a dev environment.
> 
> From: Jay Feldblum [y\_feldblum@yahoo.com](mailto:y_feldblum@yahoo.com)  
> Reply-To: "[chef@lists.opscode.com](mailto:chef@lists.opscode.com)" [chef@lists.opscode.com](mailto:chef@lists.opscode.com)  
> Date: Wednesday, November 21, 2012 8:37 AM  
> To: "[chef@lists.opscode.com](mailto:chef@lists.opscode.com)" [chef@lists.opscode.com](mailto:chef@lists.opscode.com)  
> Subject: [chef] Re: Re: Re: Roles and Versioning
> 
> Kevin,
> 
> The boundary between interface and implementation depends on the context or  
> on the viewpoint, and we need to be able to discover where that boundary is  
> in the various cases we actually end up dealing with.
> 
> For me, default and override attributes in a role seem generally to lie on  
> the implementation side of that boundary. That much seems, in most cases,  
> open-and-shut. But the content of the run-list is more of an open question  
> to me, and I suppose that, at least for now, I would end up deciding that on  
> a case-by-case basis.
> 
> Keep in mind that something might, from one viewpoint, be an interface but,  
> from another viewpoint, be an implementation.
> 
> This is of course applicable to code-type roles (roles that you keep in  
> git), and not applicable to data-type roles (roles that are not kept in  
> git).
> 
> Cheers,  
> Jay
> 
> On Wed, Nov 21, 2012 at 10:25 AM, Kevin Christen [kevin.christen@gmail.com](mailto:kevin.christen@gmail.com)  
> wrote:
> 
> > Jay,
> > 
> > Can you elaborate on what you mean by treating a role as interface? It  
> > seems to me that a run\_list is implementation. Or are you thinking that a  
> > run\_list containing other roles is an interface, while a run\_list containing  
> > recipes is an implementation?
> > 
> > Thanks,  
> > Kevin Christen
> > 
> > On Tue, Nov 20, 2012 at 12:47 PM, Jay Feldblum [y\_feldblum@yahoo.com](mailto:y_feldblum@yahoo.com)  
> > wrote:
> > 
> > > Kevin,
> > > 
> > > If you treat roles as implementation, then you will need to start  
> > > versioning them.
> > > 
> > > If you treat roles as interface, as a declaration of intent only, and  
> > > remove all implementation from them, then you will need to implement them  
> > > with an implementation cookbook, so to speak. The role will not need to be  
> > > versioned itself; only the implementation cookbook will need to be  
> > > versioned.
> > > 
> > > Cheers,  
> > > Jay

---

<div class="post-metadata">

**Author:** ![Tim\_Smith](https://avatars.discourse-cdn.com/v4/letter/t/8dc957/32.png) [@Tim\_Smith](https://discourse.chef.io/u/Tim_Smith)\
**Post date:** [November 21, 2012, 6:08pm UTC](https://discourse.chef.io/t/roles-and-versioning/3321/12 "2012-11-21T18:08:23Z")

</div>

Per environment run\_lists would be a possible solution, but with 20  
environments to manage it seems like a management nightmare to be juggling  
run lists in that form. It also really seems backwards from how Chef  
generally gates change. Environments dictate cookbook versions. No one  
would ever think of having particular parts of cookbooks that would run  
depending on what environment they're in. I hope that Opscode sees the  
light here and adds some simple cookbook style version pinning. It would  
make a lot of people happy.

Tim Smith  
Operations Engineer, SaaS Operations  
M: +1 707.738.8132  
TW: @tas50  
webtrends [http://www.webtrends.com/](http://www.webtrends.com/)  
Real-Time Relevance. Remarkable ROI.  
London | Portland | San Francisco | Melbourne | Tokyo

On 11/21/12 9:54 AM, "Mike" [miketheman@gmail.com](mailto:miketheman@gmail.com) wrote:

> Tim:  
> For environments specific run lists, use Environment Run Lists.  
> [http://wiki.opscode.com/display/chef/Environments#Environments-PerEnvironm](http://wiki.opscode.com/display/chef/Environments#Environments-PerEnvironm)  
> entRunListsinRoles
> 
> -M
> 
> On Wed, Nov 21, 2012 at 12:50 PM, Tim Smith [Tim.Smith@webtrends.com](mailto:Tim.Smith@webtrends.com)  
> wrote:
> 
> > I understand the desire to keep roles simple and generic, but the lack  
> > of  
> > versioning in roles is a really huge pain point in working with Chef. I  
> > never add attributes to my roles to eliminate configuration from the  
> > roles,  
> > but there is often a need to change the run list portion of the roles.  
> > I  
> > use a single Chef server for my staging and production environments so I  
> > need to be able to test changes for a release before pushing those  
> > changes  
> > to prod. Right now if someone on my Dev team makes any modifications  
> > to the  
> > run list in a role I either have to push it to production immediately or  
> > undergo very manual renaming of roles / node changes. Versions would  
> > eliminate these problems entirely as I could use version 1 of a role in  
> > production while changing run lists entirely in a dev environment.
> > 
> > From: Jay Feldblum [y\_feldblum@yahoo.com](mailto:y_feldblum@yahoo.com)  
> > Reply-To: "[chef@lists.opscode.com](mailto:chef@lists.opscode.com)" [chef@lists.opscode.com](mailto:chef@lists.opscode.com)  
> > Date: Wednesday, November 21, 2012 8:37 AM  
> > To: "[chef@lists.opscode.com](mailto:chef@lists.opscode.com)" [chef@lists.opscode.com](mailto:chef@lists.opscode.com)  
> > Subject: [chef] Re: Re: Re: Roles and Versioning
> > 
> > Kevin,
> > 
> > The boundary between interface and implementation depends on the  
> > context or  
> > on the viewpoint, and we need to be able to discover where that  
> > boundary is  
> > in the various cases we actually end up dealing with.
> > 
> > For me, default and override attributes in a role seem generally to lie  
> > on  
> > the implementation side of that boundary. That much seems, in most  
> > cases,  
> > open-and-shut. But the content of the run-list is more of an open  
> > question  
> > to me, and I suppose that, at least for now, I would end up deciding  
> > that on  
> > a case-by-case basis.
> > 
> > Keep in mind that something might, from one viewpoint, be an interface  
> > but,  
> > from another viewpoint, be an implementation.
> > 
> > This is of course applicable to code-type roles (roles that you keep in  
> > git), and not applicable to data-type roles (roles that are not kept in  
> > git).
> > 
> > Cheers,  
> > Jay
> > 
> > On Wed, Nov 21, 2012 at 10:25 AM, Kevin Christen  
> > [kevin.christen@gmail.com](mailto:kevin.christen@gmail.com)  
> > wrote:
> > 
> > > Jay,
> > > 
> > > Can you elaborate on what you mean by treating a role as interface? It  
> > > seems to me that a run\_list is implementation. Or are you thinking  
> > > that a  
> > > run\_list containing other roles is an interface, while a run\_list  
> > > containing  
> > > recipes is an implementation?
> > > 
> > > Thanks,  
> > > Kevin Christen
> > > 
> > > On Tue, Nov 20, 2012 at 12:47 PM, Jay Feldblum [y\_feldblum@yahoo.com](mailto:y_feldblum@yahoo.com)  
> > > wrote:
> > > 
> > > > Kevin,
> > > > 
> > > > If you treat roles as implementation, then you will need to start  
> > > > versioning them.
> > > > 
> > > > If you treat roles as interface, as a declaration of intent only, and  
> > > > remove all implementation from them, then you will need to implement  
> > > > them  
> > > > with an implementation cookbook, so to speak. The role will not need  
> > > > to be  
> > > > versioned itself; only the implementation cookbook will need to be  
> > > > versioned.
> > > > 
> > > > Cheers,  
> > > > Jay

---

<div class="post-metadata">

**Author:** ![Jay\_Feldblum](https://avatars.discourse-cdn.com/v4/letter/j/9fc29f/32.png) [@Jay\_Feldblum](https://discourse.chef.io/u/Jay_Feldblum)\
**Post date:** [November 22, 2012, 12:13am UTC](https://discourse.chef.io/t/roles-and-versioning/3321/13 "2012-11-22T00:13:02Z")

</div>

Tim,

Another option available to you is that you could have multiple  
chef-servers, one per infrastructure (i.e. a test infrastructure with a  
chef-server for the test infrastructure), and have a branch per  
infrastructure as well. You can, at your leisure, merge from one branch  
(master) into another (infra-test); and you can, at your leisure, sync the  
cookbooks from a branch to a chef-server for that branch (possibly using  
knife-essentials).

Cheers,  
Jay

On Wed, Nov 21, 2012 at 1:08 PM, Tim Smith [Tim.Smith@webtrends.com](mailto:Tim.Smith@webtrends.com) wrote:

> Per environment run\_lists would be a possible solution, but with 20  
> environments to manage it seems like a management nightmare to be juggling  
> run lists in that form. It also really seems backwards from how Chef  
> generally gates change. Environments dictate cookbook versions. No one  
> would ever think of having particular parts of cookbooks that would run  
> depending on what environment they're in. I hope that Opscode sees the  
> light here and adds some simple cookbook style version pinning. It would  
> make a lot of people happy.
> 
> Tim Smith  
> Operations Engineer, SaaS Operations  
> M: +1 707.738.8132  
> TW: @tas50  
> webtrends [http://www.webtrends.com/](http://www.webtrends.com/)  
> Real-Time Relevance. Remarkable ROI.  
> London | Portland | San Francisco | Melbourne | Tokyo
> 
> On 11/21/12 9:54 AM, "Mike" [miketheman@gmail.com](mailto:miketheman@gmail.com) wrote:
> 
> > Tim:  
> > For environments specific run lists, use Environment Run Lists.
> 
> [http://wiki.opscode.com/display/chef/Environments#Environments-PerEnvironm](http://wiki.opscode.com/display/chef/Environments#Environments-PerEnvironm)
> 
> > entRunListsinRoles
> > 
> > -M
> > 
> > On Wed, Nov 21, 2012 at 12:50 PM, Tim Smith [Tim.Smith@webtrends.com](mailto:Tim.Smith@webtrends.com)  
> > wrote:
> > 
> > > I understand the desire to keep roles simple and generic, but the lack  
> > > of  
> > > versioning in roles is a really huge pain point in working with Chef. I  
> > > never add attributes to my roles to eliminate configuration from the  
> > > roles,  
> > > but there is often a need to change the run list portion of the roles.  
> > > I  
> > > use a single Chef server for my staging and production environments so I  
> > > need to be able to test changes for a release before pushing those  
> > > changes  
> > > to prod. Right now if someone on my Dev team makes any modifications  
> > > to the  
> > > run list in a role I either have to push it to production immediately or  
> > > undergo very manual renaming of roles / node changes. Versions would  
> > > eliminate these problems entirely as I could use version 1 of a role in  
> > > production while changing run lists entirely in a dev environment.
> > > 
> > > From: Jay Feldblum [y\_feldblum@yahoo.com](mailto:y_feldblum@yahoo.com)  
> > > Reply-To: "[chef@lists.opscode.com](mailto:chef@lists.opscode.com)" [chef@lists.opscode.com](mailto:chef@lists.opscode.com)  
> > > Date: Wednesday, November 21, 2012 8:37 AM  
> > > To: "[chef@lists.opscode.com](mailto:chef@lists.opscode.com)" [chef@lists.opscode.com](mailto:chef@lists.opscode.com)  
> > > Subject: [chef] Re: Re: Re: Roles and Versioning
> > > 
> > > Kevin,
> > > 
> > > The boundary between interface and implementation depends on the  
> > > context or  
> > > on the viewpoint, and we need to be able to discover where that  
> > > boundary is  
> > > in the various cases we actually end up dealing with.
> > > 
> > > For me, default and override attributes in a role seem generally to lie  
> > > on  
> > > the implementation side of that boundary. That much seems, in most  
> > > cases,  
> > > open-and-shut. But the content of the run-list is more of an open  
> > > question  
> > > to me, and I suppose that, at least for now, I would end up deciding  
> > > that on  
> > > a case-by-case basis.
> > > 
> > > Keep in mind that something might, from one viewpoint, be an interface  
> > > but,  
> > > from another viewpoint, be an implementation.
> > > 
> > > This is of course applicable to code-type roles (roles that you keep in  
> > > git), and not applicable to data-type roles (roles that are not kept in  
> > > git).
> > > 
> > > Cheers,  
> > > Jay
> > > 
> > > On Wed, Nov 21, 2012 at 10:25 AM, Kevin Christen  
> > > [kevin.christen@gmail.com](mailto:kevin.christen@gmail.com)  
> > > wrote:
> > > 
> > > > Jay,
> > > > 
> > > > Can you elaborate on what you mean by treating a role as interface? It  
> > > > seems to me that a run\_list is implementation. Or are you thinking  
> > > > that a  
> > > > run\_list containing other roles is an interface, while a run\_list  
> > > > containing  
> > > > recipes is an implementation?
> > > > 
> > > > Thanks,  
> > > > Kevin Christen
> > > > 
> > > > On Tue, Nov 20, 2012 at 12:47 PM, Jay Feldblum [y\_feldblum@yahoo.com](mailto:y_feldblum@yahoo.com)  
> > > > wrote:
> > > > 
> > > > > Kevin,
> > > > > 
> > > > > If you treat roles as implementation, then you will need to start  
> > > > > versioning them.
> > > > > 
> > > > > If you treat roles as interface, as a declaration of intent only, and  
> > > > > remove all implementation from them, then you will need to implement  
> > > > > them  
> > > > > with an implementation cookbook, so to speak. The role will not need  
> > > > > to be  
> > > > > versioned itself; only the implementation cookbook will need to be  
> > > > > versioned.
> > > > > 
> > > > > Cheers,  
> > > > > Jay

---

<div class="post-metadata">

**Author:** ![Michael\_Glenney](https://avatars.discourse-cdn.com/v4/letter/m/a9adbd/32.png) [@Michael\_Glenney](https://discourse.chef.io/u/Michael_Glenney)\
**Post date:** [November 22, 2012, 2:23pm UTC](https://discourse.chef.io/t/roles-and-versioning/3321/14 "2012-11-22T14:23:02Z")

</div>

Kevin,

We eliminated roles completely because of their lack of versioning. We replaced them with something we call "top level cookbooks" which define cookbook version constraints in the metadata and the run list in a recipe with includes.

We handle passed in attributes with the json passed to the chef run.

Michael Glenney  
Sent from my iPhone

On Nov 21, 2012, at 8:25 AM, Kevin Christen [kevin.christen@gmail.com](mailto:kevin.christen@gmail.com) wrote:

> Jay,
> 
> Can you elaborate on what you mean by treating a role as interface? It seems to me that a run\_list is implementation. Or are you thinking that a run\_list containing other roles is an interface, while a run\_list containing recipes is an implementation?
> 
> Thanks,  
> Kevin Christen
> 
> On Tue, Nov 20, 2012 at 12:47 PM, Jay Feldblum [y\_feldblum@yahoo.com](mailto:y_feldblum@yahoo.com) wrote:
> 
> > Kevin,
> > 
> > If you treat roles as implementation, then you will need to start versioning them.
> > 
> > If you treat roles as interface, as a declaration of intent only, and remove all implementation from them, then you will need to implement them with an implementation cookbook, so to speak. The role will not need to be versioned itself; only the implementation cookbook will need to be versioned.
> > 
> > Cheers,  
> > Jay
> > 
> > On Tue, Nov 20, 2012 at 1:31 PM, Kevin Christen [kevin.christen@gmail.com](mailto:kevin.christen@gmail.com) wrote:
> > 
> > > Here's a scenario for the use of roles and cookbooks in Chef server that confuses me. I'd like to know how the community handles this situation. Imagine that I have a cookbook "foo" at version 1.0.0 with a single recipe "bar". I define a role "foo\_host" with "recipe[foo::bar]" in its run\_list.
> > > 
> > > Now imagine that I improve the "foo" cookbook by adding a "baz" recipe and increment it's version number to 1.1.0. What do I do with the role? If I add the new recipe to the "foo\_host" run\_list, I will break any nodes that won't use the latest version of the cookbook because of an environment version constraint. I can only think of a few solutions:
> > > 
> > > Version the role through its name. In other words, leave "foo\_host" alone and create a "foo\_host\_1" role with both recipes in its run\_list.  
> > > Run separate versions of chef server for each environment, as mentioned here. Update the role in only those servers who's environment will pick up the latest version of the cookbook.  
> > > Don't use a role for this purpose. Instead, define a separate, versioned "wrapper" cookbook as described by Bryan Berry here.  
> > > Is there a community consensus on how to deal with this situation?
> > > 
> > > Thanks,  
> > > Kevin Christen

---

<div class="post-metadata">

**Author:** ![Brian\_Akins](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/brian_akins/32/298_2.png) [@Brian\_Akins](https://discourse.chef.io/u/Brian_Akins)\
**Post date:** [November 27, 2012, 1:35am UTC](https://discourse.chef.io/t/roles-and-versioning/3321/15 "2012-11-27T01:35:17Z")

</div>

On Nov 21, 2012, at 12:50 PM, Tim Smith [Tim.Smith@Webtrends.com](mailto:Tim.Smith@Webtrends.com) wrote:

> Right now if someone on my Dev team makes any modifications to the run list in a role I either have to push it to production immediately or undergo very manual renaming of roles / node changes. Versions would eliminate these problems entirely as I could use version 1 of a role in production while changing run lists entirely in a dev environment.

Catching up on email, so someone may have mentioned this already:

Have a listen to this:

> **[Jamie Winsor and Michael Ivey Skool us on Berkshelf - Food Fight](http://foodfightshow.org/2012/08/jamie-winsor-and-michael-ivey-skool-us-on-berkshelf.html)**
>
> Show Date: Thursday August 1st, 18:00 (Rome) 12:00 Alabama 09:00 LA Panel
> What’s Cookin’ In the News
> Cookbook News Outline
> Picks
> Download …

We are thinking about doing the same as RiotGames - using cookbooks rather than roles and environments.

--Brian

---

<div class="post-metadata">

**Author:** ![reset](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/reset/32/490_2.png) [@reset](https://discourse.chef.io/u/reset)\
**Post date:** [November 27, 2012, 8:18am UTC](https://discourse.chef.io/t/roles-and-versioning/3321/16 "2012-11-27T08:18:48Z")

</div>

Hey Brian,

We are using environments heavily, just not roles. We use environments to pin cookbook versions for all the nodes in that environment.

Jamie Winsor  
@resetexistence

On Nov 26, 2012, at 8:35 PM, Brian Akins [brian@akins.org](mailto:brian@akins.org) wrote:

> On Nov 21, 2012, at 12:50 PM, Tim Smith [Tim.Smith@Webtrends.com](mailto:Tim.Smith@Webtrends.com) wrote:
> 
> > Right now if someone on my Dev team makes any modifications to the run list in a role I either have to push it to production immediately or undergo very manual renaming of roles / node changes. Versions would eliminate these problems entirely as I could use version 1 of a role in production while changing run lists entirely in a dev environment.
> 
> Catching up on email, so someone may have mentioned this already:
> 
> Have a listen to this:
> 
> [Jamie Winsor and Michael Ivey Skool us on Berkshelf - Food Fight](http://foodfightshow.org/2012/08/jamie-winsor-and-michael-ivey-skool-us-on-berkshelf.html)
> 
> We are thinking about doing the same as RiotGames - using cookbooks rather than roles and environments.
> 
> --Brian