# Should I be using roles?

**URL:** <https://discourse.chef.io/t/should-i-be-using-roles/5723>\
**Category:** Chef Infra (archive)\
**Created:** [September 15, 2014, 8:20pm UTC](https://discourse.chef.io/t/should-i-be-using-roles/5723 "2014-09-15T20:20:54Z")\
**Posts on this page:** 16\
**Page:** 1

<div class="post-metadata">

**Author:** ![fletchowns](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/fletchowns/32/53_2.png) [@fletchowns](https://discourse.chef.io/u/fletchowns)\
**Post date:** [September 15, 2014, 8:20pm UTC](https://discourse.chef.io/t/should-i-be-using-roles/5723/1 "2014-09-15T20:20:54Z")

</div>

After googling around and reading various blog posts about roles, I’m still  
not sure if I should be using them. Since I’m new to chef, I wanted to  
describe my line of thinking and hear if maybe I’m going about things the  
wrong way.

There are certain things I think might be the same on all my servers, so I  
created a base\_role.rb. It’s fairly simple: specifies set\_fqdn=\*.  
[mycompany.com](http://mycompany.com), some openssh & postfix attributes, and a run\_list of  
hostname, openssh, fail2ban, and postfix.

So now I want to spin up a jenkins server. I see there is a popular  
community cookbook with some LWRPs that I’ll probably use, so I run `berks cookbook mycompany-jenkins` to create my jenkins cookbook and add “depends  
’jenkins’” to the metadata.rb file. But I also need the stuff from my  
base\_role on the jenkins server, so I create a new role,  
mycompany\_jenkins.rb. Inside that role I specify some attributes for the  
java version, and the run\_list is role[base\_role], java, maven, jenkins,  
and mycompany-jenkins. Or maybe the attributes I specified in the role  
should actually be in the mycompany-jenkins cookbook default attributes?

Now I go back to the mycompany-jenkins metadata.rb file and start adding  
more depends lines for hostname, openssh, fail2ban, postfix, java, and  
maven. Even though the mycompany-jenkins cookbook doesn’t have anything in  
it yet, it depends on all these things because of the role. But the role  
doesn’t even live inside the cookbook, why should the cookbook have to  
declare all those dependencies. Now I’m thinking that maybe my base\_role  
should be a recipe instead? Then berks could figure out all those  
dependencies for me. Or should the run\_list I put in the rule actually be a  
couple of include\_recipe lines in my default.rb? That would make all the  
depends lines in the metadata make more sense.

The 2nd google result for “chef roles” is this article  
[http://www.getchef.com/blog/2013/11/19/chef-roles-arent-evil/](http://www.getchef.com/blog/2013/11/19/chef-roles-arent-evil/) that states  
versioned roles are likely coming with Chef 12. I was thinking maybe that  
is something that will help me here. So I googled "chef 12 versioned roles"  
and it led me to CHEF-4837 [https://tickets.opscode.com/browse/CHEF-4837](https://tickets.opscode.com/browse/CHEF-4837).  
It didn’t really add much clarity though, I am still confused where the  
discussion ends and it doesn’t seem to pick up on github.

At any rate, hopefully this describes some of my confusion with the use of  
roles. Please help steer me in the right direction.

Thanks in advance!

---

<div class="post-metadata">

**Author:** ![JOHN\_HASTY](https://avatars.discourse-cdn.com/v4/letter/j/0ea827/32.png) [@JOHN\_HASTY](https://discourse.chef.io/u/JOHN_HASTY)\
**Post date:** [September 15, 2014, 8:32pm UTC](https://discourse.chef.io/t/should-i-be-using-roles/5723/2 "2014-09-15T20:32:26Z")

</div>

I quit using roles to trigger running recipes. My roles now contain a  
single recipe that is a no-op.

I did this because:

1. Using roles for executing recipes makes restarts more difficult
2. I am moving toward an orchestration engine (Urban Code Deploy). It will  
execute the scripts in order and is easier to restart.
3. I do use roles to indicate the type of resources on a node, such as db  
or web server.

JOHN HASTY  
Software as a Service - DevOps  
Software Group

Phone: 1-512-804-9968 IBM  
E-mail: [jahasty@us.ibm.com](mailto:jahasty@us.ibm.com)  
2407 S Congress Ave Ste E-350  
Austin, TX 78704  
United States

From: Greg Barker [fletch@fletchowns.net](mailto:fletch@fletchowns.net)  
To: [chef@lists.opscode.com](mailto:chef@lists.opscode.com)  
Date: 09/15/2014 03:21 PM  
Subject: [chef] Should I be using roles?

After googling around and reading various blog posts about roles, I’m still  
not sure if I should be using them. Since I’m new to chef, I wanted to  
describe my line of thinking and hear if maybe I’m going about things the  
wrong way.

There are certain things I think might be the same on all my servers, so I  
created a base\_role.rb. It’s fairly simple: specifies set\_fqdn=\*.  
[mycompany.com](http://mycompany.com), some openssh & postfix attributes, and a run\_list of  
hostname, openssh, fail2ban, and postfix.

So now I want to spin up a jenkins server. I see there is a popular  
community cookbook with some LWRPs that I’ll probably use, so I run `berks cookbook mycompany-jenkins` to create my jenkins cookbook and add “depends  
’jenkins’” to the metadata.rb file. But I also need the stuff from my  
base\_role on the jenkins server, so I create a new role,  
mycompany\_jenkins.rb. Inside that role I specify some attributes for the  
java version, and the run\_list is role[base\_role], java, maven, jenkins,  
and mycompany-jenkins. Or maybe the attributes I specified in the role  
should actually be in the mycompany-jenkins cookbook default attributes?

Now I go back to the mycompany-jenkins metadata.rb file and start adding  
more depends lines for hostname, openssh, fail2ban, postfix, java, and  
maven. Even though the mycompany-jenkins cookbook doesn’t have anything in  
it yet, it depends on all these things because of the role. But the role  
doesn’t even live inside the cookbook, why should the cookbook have to  
declare all those dependencies. Now I’m thinking that maybe my base\_role  
should be a recipe instead? Then berks could figure out all those  
dependencies for me. Or should the run\_list I put in the rule actually be a  
couple of include\_recipe lines in my default.rb? That would make all the  
depends lines in the metadata make more sense.

The 2nd google result for “chef roles” is this article that states  
versioned roles are likely coming with Chef 12. I was thinking maybe that  
is something that will help me here. So I googled "chef 12 versioned roles"  
and it led me to CHEF-4837. It didn’t really add much clarity though, I am  
still confused where the discussion ends and it doesn’t seem to pick up on  
github.

At any rate, hopefully this describes some of my confusion with the use of  
roles. Please help steer me in the right direction.

Thanks in advance!

---

<div class="post-metadata">

**Author:** ![Morgan\_Blackthorne](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/morgan_blackthorne/32/100_2.png) [@Morgan\_Blackthorne](https://discourse.chef.io/u/Morgan_Blackthorne)\
**Post date:** [September 15, 2014, 8:46pm UTC](https://discourse.chef.io/t/should-i-be-using-roles/5723/3 "2014-09-15T20:46:43Z")

</div>

We use a combination of roles and application cookbooks. Roles are usually  
for overriding info (different MySQL configs for different clusters) or  
combining things (like our base cookbook with the vmware tools cookbook).  
We use roles pretty lightly, though, bearing in mind that they're not  
versionable. If things start getting complicated, then it's time to pull  
stuff back out and put it into a cookbook instead.

--  
~_~ StormeRider ~_~

"Every world needs its heroes [...] They inspire us to be better than we  
are. And they protect from the darkness that's just around the corner."

(from Smallville Season 6x1: "Zod")

On why I hate the phrase "that's so lame"... [http://bit.ly/Ps3uSS](http://bit.ly/Ps3uSS)

On Mon, Sep 15, 2014 at 1:20 PM, Greg Barker [fletch@fletchowns.net](mailto:fletch@fletchowns.net) wrote:

> After googling around and reading various blog posts about roles, I'm  
> still not sure if I should be using them. Since I'm new to chef, I wanted  
> to describe my line of thinking and hear if maybe I'm going about things  
> the wrong way.
> 
> There are certain things I think might be the same on all my servers, so I  
> created a base\_role.rb. It's fairly simple: specifies set\_fqdn=\*.  
> [mycompany.com](http://mycompany.com), some openssh & postfix attributes, and a run\_list of  
> hostname, openssh, fail2ban, and postfix.
> 
> So now I want to spin up a jenkins server. I see there is a popular  
> community cookbook with some LWRPs that I'll probably use, so I run `berks cookbook mycompany-jenkins` to create my jenkins cookbook and add "depends  
> 'jenkins'" to the metadata.rb file. But I also need the stuff from my  
> base\_role on the jenkins server, so I create a new role,  
> mycompany\_jenkins.rb. Inside that role I specify some attributes for the  
> java version, and the run\_list is role[base\_role], java, maven, jenkins,  
> and mycompany-jenkins. Or maybe the attributes I specified in the role  
> should actually be in the mycompany-jenkins cookbook default attributes?
> 
> Now I go back to the mycompany-jenkins metadata.rb file and start adding  
> more depends lines for hostname, openssh, fail2ban, postfix, java, and  
> maven. Even though the mycompany-jenkins cookbook doesn't have anything in  
> it yet, it depends on all these things because of the role. But the role  
> doesn't even live inside the cookbook, why should the cookbook have to  
> declare all those dependencies. Now I'm thinking that maybe my base\_role  
> should be a recipe instead? Then berks could figure out all those  
> dependencies for me. Or should the run\_list I put in the rule actually be a  
> couple of include\_recipe lines in my default.rb? That would make all the  
> depends lines in the metadata make more sense.
> 
> The 2nd google result for "chef roles" is this article  
> [http://www.getchef.com/blog/2013/11/19/chef-roles-arent-evil/](http://www.getchef.com/blog/2013/11/19/chef-roles-arent-evil/) that  
> states versioned roles are likely coming with Chef 12. I was thinking maybe  
> that is something that will help me here. So I googled "chef 12 versioned  
> roles" and it led me to CHEF-4837  
> [https://tickets.opscode.com/browse/CHEF-4837](https://tickets.opscode.com/browse/CHEF-4837). It didn't really add much  
> clarity though, I am still confused where the discussion ends and it  
> doesn't seem to pick up on github.
> 
> At any rate, hopefully this describes some of my confusion with the use of  
> roles. Please help steer me in the right direction.
> 
> Thanks in advance!

---

<div class="post-metadata">

**Author:** ![Kenneth\_Barry1](https://avatars.discourse-cdn.com/v4/letter/k/cc9497/32.png) [@Kenneth\_Barry1](https://discourse.chef.io/u/Kenneth_Barry1)\
**Post date:** [September 15, 2014, 11:47pm UTC](https://discourse.chef.io/t/should-i-be-using-roles/5723/4 "2014-09-15T23:47:02Z")

</div>

There is a strong argument for not using roles all together.

One of the main arguments is that they are not versioned. Instead, going  
with more, and more granular cookbooks (Which are versioned). Not an expert  
on it, but this is a core philosophy or the "BerkShelf" way.

On Mon, Sep 15, 2014 at 1:46 PM, Morgan Blackthorne [stormerider@gmail.com](mailto:stormerider@gmail.com)  
wrote:

> We use a combination of roles and application cookbooks. Roles are usually  
> for overriding info (different MySQL configs for different clusters) or  
> combining things (like our base cookbook with the vmware tools cookbook).  
> We use roles pretty lightly, though, bearing in mind that they're not  
> versionable. If things start getting complicated, then it's time to pull  
> stuff back out and put it into a cookbook instead.
> 
> --  
> ~_~ StormeRider ~_~
> 
> "Every world needs its heroes [...] They inspire us to be better than we  
> are. And they protect from the darkness that's just around the corner."
> 
> (from Smallville Season 6x1: "Zod")
> 
> On why I hate the phrase "that's so lame"... [http://bit.ly/Ps3uSS](http://bit.ly/Ps3uSS)
> 
> On Mon, Sep 15, 2014 at 1:20 PM, Greg Barker [fletch@fletchowns.net](mailto:fletch@fletchowns.net)  
> wrote:
> 
> > After googling around and reading various blog posts about roles, I'm  
> > still not sure if I should be using them. Since I'm new to chef, I wanted  
> > to describe my line of thinking and hear if maybe I'm going about things  
> > the wrong way.
> > 
> > There are certain things I think might be the same on all my servers, so  
> > I created a base\_role.rb. It's fairly simple: specifies set\_fqdn=\*.  
> > [mycompany.com](http://mycompany.com), some openssh & postfix attributes, and a run\_list of  
> > hostname, openssh, fail2ban, and postfix.
> > 
> > So now I want to spin up a jenkins server. I see there is a popular  
> > community cookbook with some LWRPs that I'll probably use, so I run `berks cookbook mycompany-jenkins` to create my jenkins cookbook and add "depends  
> > 'jenkins'" to the metadata.rb file. But I also need the stuff from my  
> > base\_role on the jenkins server, so I create a new role,  
> > mycompany\_jenkins.rb. Inside that role I specify some attributes for the  
> > java version, and the run\_list is role[base\_role], java, maven, jenkins,  
> > and mycompany-jenkins. Or maybe the attributes I specified in the role  
> > should actually be in the mycompany-jenkins cookbook default attributes?
> > 
> > Now I go back to the mycompany-jenkins metadata.rb file and start adding  
> > more depends lines for hostname, openssh, fail2ban, postfix, java, and  
> > maven. Even though the mycompany-jenkins cookbook doesn't have anything in  
> > it yet, it depends on all these things because of the role. But the role  
> > doesn't even live inside the cookbook, why should the cookbook have to  
> > declare all those dependencies. Now I'm thinking that maybe my base\_role  
> > should be a recipe instead? Then berks could figure out all those  
> > dependencies for me. Or should the run\_list I put in the rule actually be a  
> > couple of include\_recipe lines in my default.rb? That would make all the  
> > depends lines in the metadata make more sense.
> > 
> > The 2nd google result for "chef roles" is this article  
> > [http://www.getchef.com/blog/2013/11/19/chef-roles-arent-evil/](http://www.getchef.com/blog/2013/11/19/chef-roles-arent-evil/) that  
> > states versioned roles are likely coming with Chef 12. I was thinking maybe  
> > that is something that will help me here. So I googled "chef 12 versioned  
> > roles" and it led me to CHEF-4837  
> > [https://tickets.opscode.com/browse/CHEF-4837](https://tickets.opscode.com/browse/CHEF-4837). It didn't really add  
> > much clarity though, I am still confused where the discussion ends and it  
> > doesn't seem to pick up on github.
> > 
> > At any rate, hopefully this describes some of my confusion with the use  
> > of roles. Please help steer me in the right direction.
> > 
> > Thanks in advance!

--

Kenneth Barry  
TuneIn | Build and Release Engineer  
M: 409-673-0544

> **[TuneIn | Free Internet Radio | Live News, Sports, Music, Audiobooks, and...](https://tunein.com/)**
>
> Listen to free internet radio, news, sports, music, audiobooks, and podcasts. Stream live CNN, FOX News Radio, and MSNBC. Plus 100,000 AM/FM radio stations featuring music, news, and local sports talk.

---

<div class="post-metadata">

**Author:** ![Greg\_Zapp](https://avatars.discourse-cdn.com/v4/letter/g/cab0a1/32.png) [@Greg\_Zapp](https://discourse.chef.io/u/Greg_Zapp)\
**Post date:** [September 16, 2014, 12:02am UTC](https://discourse.chef.io/t/should-i-be-using-roles/5723/5 "2014-09-16T00:02:30Z")

</div>

I also do not use roles. I use a "role" recipe that includes all my other  
recipes. If I needed to search on type I could store that in a different  
attribute or tag.

-Greg

On Tue, Sep 16, 2014 at 11:47 AM, Kenneth Barry [kbarry@tunein.com](mailto:kbarry@tunein.com) wrote:

> There is a strong argument for not using roles all together.
> 
> One of the main arguments is that they are not versioned. Instead, going  
> with more, and more granular cookbooks (Which are versioned). Not an expert  
> on it, but this is a core philosophy or the "BerkShelf" way.
> 
> On Mon, Sep 15, 2014 at 1:46 PM, Morgan Blackthorne \<[stormerider@gmail.com](mailto:stormerider@gmail.com)
> 
> > wrote:
> 
> > We use a combination of roles and application cookbooks. Roles are  
> > usually for overriding info (different MySQL configs for different  
> > clusters) or combining things (like our base cookbook with the vmware tools  
> > cookbook). We use roles pretty lightly, though, bearing in mind that  
> > they're not versionable. If things start getting complicated, then it's  
> > time to pull stuff back out and put it into a cookbook instead.
> > 
> > --  
> > ~_~ StormeRider ~_~
> > 
> > "Every world needs its heroes [...] They inspire us to be better than we  
> > are. And they protect from the darkness that's just around the corner."
> > 
> > (from Smallville Season 6x1: "Zod")
> > 
> > On why I hate the phrase "that's so lame"... [http://bit.ly/Ps3uSS](http://bit.ly/Ps3uSS)
> > 
> > On Mon, Sep 15, 2014 at 1:20 PM, Greg Barker [fletch@fletchowns.net](mailto:fletch@fletchowns.net)  
> > wrote:
> > 
> > > After googling around and reading various blog posts about roles, I'm  
> > > still not sure if I should be using them. Since I'm new to chef, I wanted  
> > > to describe my line of thinking and hear if maybe I'm going about things  
> > > the wrong way.
> > > 
> > > There are certain things I think might be the same on all my servers, so  
> > > I created a base\_role.rb. It's fairly simple: specifies set\_fqdn=\*.  
> > > [mycompany.com](http://mycompany.com), some openssh & postfix attributes, and a run\_list of  
> > > hostname, openssh, fail2ban, and postfix.
> > > 
> > > So now I want to spin up a jenkins server. I see there is a popular  
> > > community cookbook with some LWRPs that I'll probably use, so I run `berks cookbook mycompany-jenkins` to create my jenkins cookbook and add "depends  
> > > 'jenkins'" to the metadata.rb file. But I also need the stuff from my  
> > > base\_role on the jenkins server, so I create a new role,  
> > > mycompany\_jenkins.rb. Inside that role I specify some attributes for the  
> > > java version, and the run\_list is role[base\_role], java, maven, jenkins,  
> > > and mycompany-jenkins. Or maybe the attributes I specified in the role  
> > > should actually be in the mycompany-jenkins cookbook default attributes?
> > > 
> > > Now I go back to the mycompany-jenkins metadata.rb file and start adding  
> > > more depends lines for hostname, openssh, fail2ban, postfix, java, and  
> > > maven. Even though the mycompany-jenkins cookbook doesn't have anything in  
> > > it yet, it depends on all these things because of the role. But the role  
> > > doesn't even live inside the cookbook, why should the cookbook have to  
> > > declare all those dependencies. Now I'm thinking that maybe my base\_role  
> > > should be a recipe instead? Then berks could figure out all those  
> > > dependencies for me. Or should the run\_list I put in the rule actually be a  
> > > couple of include\_recipe lines in my default.rb? That would make all the  
> > > depends lines in the metadata make more sense.
> > > 
> > > The 2nd google result for "chef roles" is this article  
> > > [http://www.getchef.com/blog/2013/11/19/chef-roles-arent-evil/](http://www.getchef.com/blog/2013/11/19/chef-roles-arent-evil/) that  
> > > states versioned roles are likely coming with Chef 12. I was thinking maybe  
> > > that is something that will help me here. So I googled "chef 12 versioned  
> > > roles" and it led me to CHEF-4837  
> > > [https://tickets.opscode.com/browse/CHEF-4837](https://tickets.opscode.com/browse/CHEF-4837). It didn't really add  
> > > much clarity though, I am still confused where the discussion ends and it  
> > > doesn't seem to pick up on github.
> > > 
> > > At any rate, hopefully this describes some of my confusion with the use  
> > > of roles. Please help steer me in the right direction.
> > > 
> > > Thanks in advance!
> 
> --
> 
> Kenneth Barry  
> TuneIn | Build and Release Engineer  
> M: 409-673-0544  
> [www.tunein.com](http://www.tunein.com)

---

<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:** [September 16, 2014, 12:08am UTC](https://discourse.chef.io/t/should-i-be-using-roles/5723/6 "2014-09-16T00:08:55Z")

</div>

I use it pretty extensively, and with lot of joy. I prefer to think roles  
more like is\_a (inheritance) relationships of object oriented programming.  
2-3 level of nesting is decent, but beyond that they make run list  
difficult to read.

They are awesome when you have a flat hierarchy, with roles doing the  
assembly only.  
Roles and environments are two main ways to idiomatically customize chef  
recipes via attribute. This works 90% of the time.

The other route (wrapper recipes) tend to use attribute set/reset, which  
gets even more clunkier as things grow.  
Recipes or cookbooks in itself dont represent service (like database, nginx  
etc) like role. When we retrofit roles's functionality in recipes, you do  
the same, but you get the ruby DSL, which allows you run time  
customization. Which is good as well as bad (if i need a recipe to  
customize another recipe, its fails OCP i think, to begin with), roles on  
the other hand enforces you to think of the cookbooks reusability, and  
expose their customization via attributes.

I'll suggest using roles if all you want is to assemble a few cookbooks to  
build a service. One scheme that always worked for me is to have a base  
role, and having one role per service which adds base+ service specific  
recipes. I'll recommend using wrappper recipes if you cant do the same  
cleanly with a role (in most cases which indicated a bigger design issues  
with the underlying cookbook)

cheers  
ranjib

On Mon, Sep 15, 2014 at 4:47 PM, Kenneth Barry [kbarry@tunein.com](mailto:kbarry@tunein.com) wrote:

> There is a strong argument for not using roles all together.
> 
> One of the main arguments is that they are not versioned. Instead, going  
> with more, and more granular cookbooks (Which are versioned). Not an expert  
> on it, but this is a core philosophy or the "BerkShelf" way.
> 
> On Mon, Sep 15, 2014 at 1:46 PM, Morgan Blackthorne \<[stormerider@gmail.com](mailto:stormerider@gmail.com)
> 
> > wrote:
> 
> > We use a combination of roles and application cookbooks. Roles are  
> > usually for overriding info (different MySQL configs for different  
> > clusters) or combining things (like our base cookbook with the vmware tools  
> > cookbook). We use roles pretty lightly, though, bearing in mind that  
> > they're not versionable. If things start getting complicated, then it's  
> > time to pull stuff back out and put it into a cookbook instead.
> > 
> > --  
> > ~_~ StormeRider ~_~
> > 
> > "Every world needs its heroes [...] They inspire us to be better than we  
> > are. And they protect from the darkness that's just around the corner."
> > 
> > (from Smallville Season 6x1: "Zod")
> > 
> > On why I hate the phrase "that's so lame"... [http://bit.ly/Ps3uSS](http://bit.ly/Ps3uSS)
> > 
> > On Mon, Sep 15, 2014 at 1:20 PM, Greg Barker [fletch@fletchowns.net](mailto:fletch@fletchowns.net)  
> > wrote:
> > 
> > > After googling around and reading various blog posts about roles, I'm  
> > > still not sure if I should be using them. Since I'm new to chef, I wanted  
> > > to describe my line of thinking and hear if maybe I'm going about things  
> > > the wrong way.
> > > 
> > > There are certain things I think might be the same on all my servers, so  
> > > I created a base\_role.rb. It's fairly simple: specifies set\_fqdn=\*.  
> > > [mycompany.com](http://mycompany.com), some openssh & postfix attributes, and a run\_list of  
> > > hostname, openssh, fail2ban, and postfix.
> > > 
> > > So now I want to spin up a jenkins server. I see there is a popular  
> > > community cookbook with some LWRPs that I'll probably use, so I run `berks cookbook mycompany-jenkins` to create my jenkins cookbook and add "depends  
> > > 'jenkins'" to the metadata.rb file. But I also need the stuff from my  
> > > base\_role on the jenkins server, so I create a new role,  
> > > mycompany\_jenkins.rb. Inside that role I specify some attributes for the  
> > > java version, and the run\_list is role[base\_role], java, maven, jenkins,  
> > > and mycompany-jenkins. Or maybe the attributes I specified in the role  
> > > should actually be in the mycompany-jenkins cookbook default attributes?
> > > 
> > > Now I go back to the mycompany-jenkins metadata.rb file and start adding  
> > > more depends lines for hostname, openssh, fail2ban, postfix, java, and  
> > > maven. Even though the mycompany-jenkins cookbook doesn't have anything in  
> > > it yet, it depends on all these things because of the role. But the role  
> > > doesn't even live inside the cookbook, why should the cookbook have to  
> > > declare all those dependencies. Now I'm thinking that maybe my base\_role  
> > > should be a recipe instead? Then berks could figure out all those  
> > > dependencies for me. Or should the run\_list I put in the rule actually be a  
> > > couple of include\_recipe lines in my default.rb? That would make all the  
> > > depends lines in the metadata make more sense.
> > > 
> > > The 2nd google result for "chef roles" is this article  
> > > [http://www.getchef.com/blog/2013/11/19/chef-roles-arent-evil/](http://www.getchef.com/blog/2013/11/19/chef-roles-arent-evil/) that  
> > > states versioned roles are likely coming with Chef 12. I was thinking maybe  
> > > that is something that will help me here. So I googled "chef 12 versioned  
> > > roles" and it led me to CHEF-4837  
> > > [https://tickets.opscode.com/browse/CHEF-4837](https://tickets.opscode.com/browse/CHEF-4837). It didn't really add  
> > > much clarity though, I am still confused where the discussion ends and it  
> > > doesn't seem to pick up on github.
> > > 
> > > At any rate, hopefully this describes some of my confusion with the use  
> > > of roles. Please help steer me in the right direction.
> > > 
> > > Thanks in advance!
> 
> --
> 
> Kenneth Barry  
> TuneIn | Build and Release Engineer  
> M: 409-673-0544  
> [www.tunein.com](http://www.tunein.com)

---

<div class="post-metadata">

**Author:** ![AJ\_Christensen2](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/aj_christensen2/32/42_2.png) [@AJ\_Christensen2](https://discourse.chef.io/u/AJ_Christensen2)\
**Post date:** [September 16, 2014, 12:15am UTC](https://discourse.chef.io/t/should-i-be-using-roles/5723/7 "2014-09-16T00:15:05Z")

</div>

Yo,

Forgive my reply-all!

Roles are fine, use whatever you like. I use them all the time! They're awesome.

If you don't use roles you'll end up half ass inventing them with  
application/library/wrapper shenanigan cookbooks, or other external  
stuff -- You could put run lists in a custom API, Consul, or etcd, for  
example.

I semi-expect Chef to offer some more guidance officially soon with  
regard to version-able policy representing the cookbooks, attributes,  
version locks and execution order.

Chef-RFC RFC019 [0] is worth looking at regarding workflows and the  
ChefDK, "the berkshelf way".

I would also urge you to read Dan's proposal regarding Arbitrary  
cookbook identifiers which is used for his (experimental? prototype?)  
Policyfile implementation. It's the way I hope we all choose to  
proceed, personally. [1]

regards,

--aj (fujin)

[0] [https://github.com/opscode/chef-rfc/blob/6a239ff5dc223290d4488d76fadaeeb6d14f5ab1/rfc019-chef-workflows.md](https://github.com/opscode/chef-rfc/blob/6a239ff5dc223290d4488d76fadaeeb6d14f5ab1/rfc019-chef-workflows.md)  
[1] [Arbitrary cookbook identifiers by danielsdeleo · Pull Request #20 · chef-boneyard/chef-rfc · GitHub](https://github.com/opscode/chef-rfc/pull/20)

On Tue, Sep 16, 2014 at 8:20 AM, Greg Barker [fletch@fletchowns.net](mailto:fletch@fletchowns.net) wrote:

> After googling around and reading various blog posts about roles, I'm still  
> not sure if I should be using them. Since I'm new to chef, I wanted to  
> describe my line of thinking and hear if maybe I'm going about things the  
> wrong way.
> 
> There are certain things I think might be the same on all my servers, so I  
> created a base\_role.rb. It's fairly simple: specifies  
> set\_fqdn=\*.mycompany.com, some openssh & postfix attributes, and a run\_list  
> of hostname, openssh, fail2ban, and postfix.
> 
> So now I want to spin up a jenkins server. I see there is a popular  
> community cookbook with some LWRPs that I'll probably use, so I run `berks cookbook mycompany-jenkins` to create my jenkins cookbook and add "depends  
> 'jenkins'" to the metadata.rb file. But I also need the stuff from my  
> base\_role on the jenkins server, so I create a new role,  
> mycompany\_jenkins.rb. Inside that role I specify some attributes for the  
> java version, and the run\_list is role[base\_role], java, maven, jenkins, and  
> mycompany-jenkins. Or maybe the attributes I specified in the role should  
> actually be in the mycompany-jenkins cookbook default attributes?
> 
> Now I go back to the mycompany-jenkins metadata.rb file and start adding  
> more depends lines for hostname, openssh, fail2ban, postfix, java, and  
> maven. Even though the mycompany-jenkins cookbook doesn't have anything in  
> it yet, it depends on all these things because of the role. But the role  
> doesn't even live inside the cookbook, why should the cookbook have to  
> declare all those dependencies. Now I'm thinking that maybe my base\_role  
> should be a recipe instead? Then berks could figure out all those  
> dependencies for me. Or should the run\_list I put in the rule actually be a  
> couple of include\_recipe lines in my default.rb? That would make all the  
> depends lines in the metadata make more sense.
> 
> The 2nd google result for "chef roles" is this article that states versioned  
> roles are likely coming with Chef 12. I was thinking maybe that is something  
> that will help me here. So I googled "chef 12 versioned roles" and it led me  
> to CHEF-4837. It didn't really add much clarity though, I am still confused  
> where the discussion ends and it doesn't seem to pick up on github.
> 
> At any rate, hopefully this describes some of my confusion with the use of  
> roles. Please help steer me in the right direction.
> 
> Thanks in advance!

---

<div class="post-metadata">

**Author:** ![Michael\_deMan](https://avatars.discourse-cdn.com/v4/letter/m/a9a28c/32.png) [@Michael\_deMan](https://discourse.chef.io/u/Michael_deMan)\
**Post date:** [September 16, 2014, 12:29am UTC](https://discourse.chef.io/t/should-i-be-using-roles/5723/8 "2014-09-16T00:29:45Z")

</div>

We use roles too much but believe they are useful and have a place.

We typically end up with every node having three roles - bootstrap, base, . Where is whatever application, database or thing the node is really for.

I agree that going much beyond 3-4 could make things confusing but their additive nature is really handy and allows us to separate responsibilities for the configuration & recipes to different teams with clear delineations of ownership. We also put our run lists in the roles and will sometimes use the role to override default attributes for bootstrap/base recipes (tuning ulimits for a specific app or something).

We have run into situations where we badly wished that roles were versioned but I think that is because in our roles early on we started putting lots of application configuration information into them. Configuration information that we now realize probably should live in data bags that are leveraged by the recipes themselves.

- Mike

On Sep 15, 2014, at 5:08 PM, Ranjib Dey [dey.ranjib@gmail.com](mailto:dey.ranjib@gmail.com) wrote:

> I use it pretty extensively, and with lot of joy. I prefer to think roles more like is\_a (inheritance) relationships of object oriented programming. 2-3 level of nesting is decent, but beyond that they make run list difficult to read.
> 
> They are awesome when you have a flat hierarchy, with roles doing the assembly only.  
> Roles and environments are two main ways to idiomatically customize chef recipes via attribute. This works 90% of the time.
> 
> The other route (wrapper recipes) tend to use attribute set/reset, which gets even more clunkier as things grow.  
> Recipes or cookbooks in itself dont represent service (like database, nginx etc) like role. When we retrofit roles's functionality in recipes, you do the same, but you get the ruby DSL, which allows you run time customization. Which is good as well as bad (if i need a recipe to customize another recipe, its fails OCP i think, to begin with), roles on the other hand enforces you to think of the cookbooks reusability, and expose their customization via attributes.
> 
> I'll suggest using roles if all you want is to assemble a few cookbooks to build a service. One scheme that always worked for me is to have a base role, and having one role per service which adds base+ service specific recipes. I'll recommend using wrappper recipes if you cant do the same cleanly with a role (in most cases which indicated a bigger design issues with the underlying cookbook)
> 
> cheers  
> ranjib
> 
> On Mon, Sep 15, 2014 at 4:47 PM, Kenneth Barry [kbarry@tunein.com](mailto:kbarry@tunein.com) wrote:  
> There is a strong argument for not using roles all together.
> 
> One of the main arguments is that they are not versioned. Instead, going with more, and more granular cookbooks (Which are versioned). Not an expert on it, but this is a core philosophy or the "BerkShelf" way.
> 
> On Mon, Sep 15, 2014 at 1:46 PM, Morgan Blackthorne [stormerider@gmail.com](mailto:stormerider@gmail.com) wrote:  
> We use a combination of roles and application cookbooks. Roles are usually for overriding info (different MySQL configs for different clusters) or combining things (like our base cookbook with the vmware tools cookbook). We use roles pretty lightly, though, bearing in mind that they're not versionable. If things start getting complicated, then it's time to pull stuff back out and put it into a cookbook instead.
> 
> --  
> ~_~ StormeRider ~_~
> 
> "Every world needs its heroes [...] They inspire us to be better than we are. And they protect from the darkness that's just around the corner."
> 
> (from Smallville Season 6x1: "Zod")
> 
> On why I hate the phrase "that's so lame"... [http://bit.ly/Ps3uSS](http://bit.ly/Ps3uSS)
> 
> On Mon, Sep 15, 2014 at 1:20 PM, Greg Barker [fletch@fletchowns.net](mailto:fletch@fletchowns.net) wrote:  
> After googling around and reading various blog posts about roles, I'm still not sure if I should be using them. Since I'm new to chef, I wanted to describe my line of thinking and hear if maybe I'm going about things the wrong way.
> 
> There are certain things I think might be the same on all my servers, so I created a base\_role.rb. It's fairly simple: specifies set\_fqdn=\*.mycompany.com, some openssh & postfix attributes, and a run\_list of hostname, openssh, fail2ban, and postfix.
> 
> So now I want to spin up a jenkins server. I see there is a popular community cookbook with some LWRPs that I'll probably use, so I run `berks cookbook mycompany-jenkins` to create my jenkins cookbook and add "depends 'jenkins'" to the metadata.rb file. But I also need the stuff from my base\_role on the jenkins server, so I create a new role, mycompany\_jenkins.rb. Inside that role I specify some attributes for the java version, and the run\_list is role[base\_role], java, maven, jenkins, and mycompany-jenkins. Or maybe the attributes I specified in the role should actually be in the mycompany-jenkins cookbook default attributes?
> 
> Now I go back to the mycompany-jenkins metadata.rb file and start adding more depends lines for hostname, openssh, fail2ban, postfix, java, and maven. Even though the mycompany-jenkins cookbook doesn't have anything in it yet, it depends on all these things because of the role. But the role doesn't even live inside the cookbook, why should the cookbook have to declare all those dependencies. Now I'm thinking that maybe my base\_role should be a recipe instead? Then berks could figure out all those dependencies for me. Or should the run\_list I put in the rule actually be a couple of include\_recipe lines in my default.rb? That would make all the depends lines in the metadata make more sense.
> 
> The 2nd google result for "chef roles" is this article that states versioned roles are likely coming with Chef 12. I was thinking maybe that is something that will help me here. So I googled "chef 12 versioned roles" and it led me to CHEF-4837. It didn't really add much clarity though, I am still confused where the discussion ends and it doesn't seem to pick up on github.
> 
> At any rate, hopefully this describes some of my confusion with the use of roles. Please help steer me in the right direction.
> 
> Thanks in advance!
> 
> --  
> Kenneth Barry  
> TuneIn | Build and Release Engineer  
> M: 409-673-0544  
> [www.tunein.com](http://www.tunein.com)

---

<div class="post-metadata">

**Author:** ![kallistec](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/kallistec/32/23_2.png) [@kallistec](https://discourse.chef.io/u/kallistec)\
**Post date:** [September 16, 2014, 12:35am UTC](https://discourse.chef.io/t/should-i-be-using-roles/5723/9 "2014-09-16T00:35:37Z")

</div>

On Monday, September 15, 2014 at 5:15 PM, AJ Christensen wrote:

> Yo,
> 
> Forgive my reply-all!
> 
> Roles are fine, use whatever you like. I use them all the time! They're awesome.
> 
> If you don't use roles you'll end up half ass inventing them with  
> application/library/wrapper shenanigan cookbooks, or other external  
> stuff -- You could put run lists in a custom API, Consul, or etcd, for  
> example.
> 
> I semi-expect Chef to offer some more guidance officially soon with  
> regard to version-able policy representing the cookbooks, attributes,  
> version locks and execution order.
> 
> Chef-RFC RFC019 [0] is worth looking at regarding workflows and the  
> ChefDK, "the berkshelf way".
> 
> I would also urge you to read Dan's proposal regarding Arbitrary  
> cookbook identifiers which is used for his (experimental? prototype?)  
> Policyfile implementation. It's the way I hope we all choose to  
> proceed, personally. [1]
> 
> regards,
> 
> --aj (fujin)
> 
> [0] [https://github.com/opscode/chef-rfc/blob/6a239ff5dc223290d4488d76fadaeeb6d14f5ab1/rfc019-chef-workflows.md](https://github.com/opscode/chef-rfc/blob/6a239ff5dc223290d4488d76fadaeeb6d14f5ab1/rfc019-chef-workflows.md)  
> [1] [Arbitrary cookbook identifiers by danielsdeleo · Pull Request #20 · chef-boneyard/chef-rfc · GitHub](https://github.com/opscode/chef-rfc/pull/20)

The policyfile stuff is coming along, but definitely not at a point where you can use it in production unless you’re pretty serious about being able to fix any bugs that are blocking you. Here’s an overview of what it is, what problems it solves, and how we expect it to work:

> <https://github.com/chef-boneyard/chef-dk/blob/master/POLICYFILE_README.md>

The pertinent part of the feature is that you’ll do the “run list expansion” step on your workstation while you’re developing your cookbooks, which means that roles will be baked in to the resulting "policy lock” document. Therefore any changes to roles will be rolled out gradually as you apply the policy to sets of nodes.

It’s still too early to say what any timeline will be for the feature to be useable in a real way. I just merged the first iteration of the command line interface to chef-dk master today ([Policyfile CLI by danielsdeleo · Pull Request #157 · chef-boneyard/chef-dk · GitHub](https://github.com/opscode/chef-dk/pull/157)), but as I wrote in the aforementioned document, there’s a lot of critical features left to write, including some new server APIs (also, role support).

Whether that means you should avoid roles, or use them but be careful about how you update them, depends on your requirements and your team. There’s a lot of good perspectives in this thread to consider.

--  
Daniel DeLeo

---

<div class="post-metadata">

**Author:** ![Lamont\_Granquist\_OLD](https://avatars.discourse-cdn.com/v4/letter/l/7feea3/32.png) [@Lamont\_Granquist\_OLD](https://discourse.chef.io/u/Lamont_Granquist_OLD)\
**Post date:** [September 16, 2014, 12:36am UTC](https://discourse.chef.io/t/should-i-be-using-roles/5723/10 "2014-09-16T00:36:39Z")

</div>

We're likely to tell you to use roles. If you wind up going the role  
cookbook route and wind up in with problems with computed attributes,  
we'll tell you to put that attribute in a role. We recognize that  
roles have a weakness right now which is that they are not versioned.  
In the future they're going to be compiled into the policyfile object  
that gets shipped up to the server and defines how a given node in a  
given environment behaves.

We'll almost certainly continue to support role-less deployments, but  
we won't encourage that because the computed attribute problem is  
always going to be waiting for people who ditch roles entirely. People  
who do ditch roles and wind up with the computed attribute problem can  
continue to try to work around that problem by pushing loading  
attributes into recipe code, but that goes against best practice. We  
fixed attribute loading in Chef 11 so that people could set attributes  
deterministically in attribute files with the intent that people would  
set attributes in roles and attribute files and stop setting them in  
recipe code (where compile/converge mode issues usually troll them  
hard). We can't stop people from going that route, but when people  
wind up leaving behind them a mess of attribute mangling code directly  
in their recipes we also can't rescue whoever winds up maintaining that.

There are ways to use setting attributes in recipes that are sane (e.g.  
to set an attribute saying you did a thing or found a thing and then  
letting `knife node show` or `knife node search` look for it later),  
but if you are setting attributes in recipe code and then consuming  
those attributes later, it is almost always better to push those  
attributes into attributes files or roles.

Still you can put roles on a huge diet. You can have roles that  
include nothing more than a role cookbook. All the attribute setting  
can be moved to the role cookbook and the run\_list for the role can be  
put into include\_recipe statements in the default recipe of the  
role\_cookbook. When you do this, you should be aware that you need one  
cookbook per every role, you can't have a single role cookbook with all  
your roles in it, because all of your attribute files will be parsed  
irregardless of if that role is in the run-list. This leads to a lot  
of cookbooks, and if you are doing one-git-repo-per-cookbook (per The  
Berkshelf Way) then you will have a _lot_ of repos -- start budgeting  
for 50-100 or more for a small-medium-business size deployment.

So, roles will not be going away, they should be getting fixed and will  
be more useful in the future.

On Mon Sep 15 17:15:05 2014, AJ Christensen wrote:

> Yo,
> 
> Forgive my reply-all!
> 
> Roles are fine, use whatever you like. I use them all the time! They're awesome.
> 
> If you don't use roles you'll end up half ass inventing them with  
> application/library/wrapper shenanigan cookbooks, or other external  
> stuff -- You could put run lists in a custom API, Consul, or etcd, for  
> example.
> 
> I semi-expect Chef to offer some more guidance officially soon with  
> regard to version-able policy representing the cookbooks, attributes,  
> version locks and execution order.
> 
> Chef-RFC RFC019 [0] is worth looking at regarding workflows and the  
> ChefDK, "the berkshelf way".
> 
> I would also urge you to read Dan's proposal regarding Arbitrary  
> cookbook identifiers which is used for his (experimental? prototype?)  
> Policyfile implementation. It's the way I hope we all choose to  
> proceed, personally. [1]
> 
> regards,
> 
> --aj (fujin)
> 
> [0] [https://github.com/opscode/chef-rfc/blob/6a239ff5dc223290d4488d76fadaeeb6d14f5ab1/rfc019-chef-workflows.md](https://github.com/opscode/chef-rfc/blob/6a239ff5dc223290d4488d76fadaeeb6d14f5ab1/rfc019-chef-workflows.md)  
> [1] [Arbitrary cookbook identifiers by danielsdeleo · Pull Request #20 · chef-boneyard/chef-rfc · GitHub](https://github.com/opscode/chef-rfc/pull/20)
> 
> On Tue, Sep 16, 2014 at 8:20 AM, Greg Barker [fletch@fletchowns.net](mailto:fletch@fletchowns.net) wrote:
> 
> > After googling around and reading various blog posts about roles, I'm still  
> > not sure if I should be using them. Since I'm new to chef, I wanted to  
> > describe my line of thinking and hear if maybe I'm going about things the  
> > wrong way.
> > 
> > There are certain things I think might be the same on all my servers, so I  
> > created a base\_role.rb. It's fairly simple: specifies  
> > set\_fqdn=\*.mycompany.com, some openssh & postfix attributes, and a run\_list  
> > of hostname, openssh, fail2ban, and postfix.
> > 
> > So now I want to spin up a jenkins server. I see there is a popular  
> > community cookbook with some LWRPs that I'll probably use, so I run `berks cookbook mycompany-jenkins` to create my jenkins cookbook and add "depends  
> > 'jenkins'" to the metadata.rb file. But I also need the stuff from my  
> > base\_role on the jenkins server, so I create a new role,  
> > mycompany\_jenkins.rb. Inside that role I specify some attributes for the  
> > java version, and the run\_list is role[base\_role], java, maven, jenkins, and  
> > mycompany-jenkins. Or maybe the attributes I specified in the role should  
> > actually be in the mycompany-jenkins cookbook default attributes?
> > 
> > Now I go back to the mycompany-jenkins metadata.rb file and start adding  
> > more depends lines for hostname, openssh, fail2ban, postfix, java, and  
> > maven. Even though the mycompany-jenkins cookbook doesn't have anything in  
> > it yet, it depends on all these things because of the role. But the role  
> > doesn't even live inside the cookbook, why should the cookbook have to  
> > declare all those dependencies. Now I'm thinking that maybe my base\_role  
> > should be a recipe instead? Then berks could figure out all those  
> > dependencies for me. Or should the run\_list I put in the rule actually be a  
> > couple of include\_recipe lines in my default.rb? That would make all the  
> > depends lines in the metadata make more sense.
> > 
> > The 2nd google result for "chef roles" is this article that states versioned  
> > roles are likely coming with Chef 12. I was thinking maybe that is something  
> > that will help me here. So I googled "chef 12 versioned roles" and it led me  
> > to CHEF-4837. It didn't really add much clarity though, I am still confused  
> > where the discussion ends and it doesn't seem to pick up on github.
> > 
> > At any rate, hopefully this describes some of my confusion with the use of  
> > roles. Please help steer me in the right direction.
> > 
> > Thanks in advance!

---

<div class="post-metadata">

**Author:** ![Mark\_Harrison1](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/mark_harrison1/32/249_2.png) [@Mark\_Harrison1](https://discourse.chef.io/u/Mark_Harrison1)\
**Post date:** [September 16, 2014, 1:37am UTC](https://discourse.chef.io/t/should-i-be-using-roles/5723/11 "2014-09-16T01:37:22Z")

</div>

> Now I go back to the mycompany-jenkins metadata.rb file and start adding  
> more depends lines for hostname, openssh, fail2ban, postfix, java, and  
> maven. Even though the mycompany-jenkins cookbook doesn't have anything in  
> it yet, it depends on all these things because of the role. But the role  
> doesn't even live inside the cookbook, why should the cookbook have to  
> declare all those dependencies.

This seems to be the source of your confusion, and your question is  
valid. Why _do_ you have to declare all of these unrelated  
dependencies inside the mycompany-jenkins cookbook? If I'm  
understanding you correctly, you can leave out hostname, openssh,  
fail2ban etc from the metadata.rb of mycompany-jenkins and just leave  
them in the run list of your base role, and things will just work. You  
add your base role (or the mycompany\_jenkins role, which has the base  
role in its run list) to your node's run list, and chef will pull in  
the relevant cookbooks during the chef run.

Now, you still need to make sure these cookbooks (hostname, openssh  
and so on) get onto the chef server somehow, and I suspect this is  
where your desire to put the cookbooks in an unrelated metadata.rb  
stems from. One option (and the way things have been done in the past)  
is to put these cookbooks in your chef repository and use knife  
cookbook upload (or knife upload) to get them on the server. However,  
it can be tricky to manage and update a repository like that, and this  
is where berkshelf can help. To make use of berkshelf, you create a  
Berksfile in the root of your chef repository, and add your cookbooks  
to that file, then you can use berks install, berks update and berks  
upload to get your cookbooks onto the server without inventing fake  
dependencies.

None of the above precludes you using roles, or eschewing roles  
altogether. There are some good reasons, mentioned by others in this  
thread, for using role cookbooks, but you don't have to let your  
current problem dictate that, and you will probably be perfectly happy  
to continue to use roles in your repository.

---

<div class="post-metadata">

**Author:** ![Eric\_G\_Wolfe1](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/eric_g_wolfe1/32/90_2.png) [@Eric\_G\_Wolfe1](https://discourse.chef.io/u/Eric_G_Wolfe1)\
**Post date:** [September 16, 2014, 4:26am UTC](https://discourse.chef.io/t/should-i-be-using-roles/5723/12 "2014-09-16T04:26:15Z")

</div>

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA1

I believe the reasoning behind this doesn't really end at versioning,  
and that is too much of an oversimplification to be useful to the  
casual reader.

Roles are just data. You can in some cases screw up your data, and  
since the data is not "software" it makes it harder to test those data  
inputs on their own.

If you do a role, or wrapper, cookbook. That cookbook, or even a  
recipe within a cookbook is still a role. The cookbook happens to  
take the shape and properties of software. Software  
(cookbooks/recipes) can be easily tested and controlled with the tools  
we have like Jenkins, Kitchen, Foodcritic, and Chefspec. If it is  
one's goal to set up a delivery pipeline with quality controlled  
(tested) software with released artifacts, then cookbooks make more  
sense than pure data roles. Its just easier that way.

However, we are still doing data-driven configuration with either  
model. There is nothing inherently wrong with using roles. Its not a  
bad starting point for discovery of what could work for an  
organization. For some people roles are good enough, and they might  
have only a few static edge cases which can be covered by roles and  
commodity cookbooks alone.

Adding versions to roles, does not solve a quality control problem  
with those data objects. That alone, is a superficial reason to avoid  
them.

Eric G. Wolfe  
email: [eric.wolfe@cyclecomputing.com](mailto:eric.wolfe@cyclecomputing.com)  
cell: 304.942.3970  
twitter: @atomic\_penguin

Cycle Computing  
Leader in Utility HPC Software

[http://www.cyclecomputing.com](http://www.cyclecomputing.com)  
twitter: @cyclecomputing

On 09/15/2014 07:47 PM, Kenneth Barry wrote:

> There is a strong argument for not using roles all together.
> 
> One of the main arguments is that they are not versioned. Instead,  
> going with more, and more granular cookbooks (Which are versioned).  
> Not an expert on it, but this is a core philosophy or the  
> "BerkShelf" way.

-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1

iQEcBAEBAgAGBQJUF7vcAAoJEIu8EfDNV4biFbYH/Ag0UIm3GLPnzs4gW8uSEYj7  
SfHFkOAScHtJTrVV9SfFBAEpIiK3sgBDSDlhboc6Lqmdw3BNbL9elNMvKsqrgxqq  
sp6iuNAPJNgCJJ5aDfttFncer0+XVrctiUSIOipQOU2a71iz79O3Wl8yVk7Ps5MY  
6Ar63703u/na3Rfb3mjMeH7MVXJsKoVQOegbGwtSQyzyzwFUsGsb8KyrLt/O3Oa4  
eovnnjlejnoVMau05tOfZkwetQFWRkExE0GEaVODVV5FmyBc1b3SnjQ/OOCygQ0a  
4lJibYCNdtg0dmj06aBYqpwH/r7xUDNLamozq62hWsaWnk6ZCstAgyn9D+nkqHw=  
=Qmhx  
-----END PGP SIGNATURE-----

---

<div class="post-metadata">

**Author:** ![fletchowns](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/fletchowns/32/53_2.png) [@fletchowns](https://discourse.chef.io/u/fletchowns)\
**Post date:** [September 16, 2014, 8:48am UTC](https://discourse.chef.io/t/should-i-be-using-roles/5723/13 "2014-09-16T08:48:09Z")

</div>

Thank you for all the feedback. Very helpful to hear all these different  
perspectives on the matter.

Regarding Mark's comments, perhaps the problem is that I am not using knife  
or chef server yet, this is just using a Vagrantfile & Berksfile that live  
in the mycompany-jenkins cookbook. If I don't include the dependencies of  
base\_role in the metadata.rb for the mycompany-jenkins cookbook, berkshelf  
does not make vendor the dependency cookbooks into the VM and my run fails  
with: Chef::Exceptions::CookbookNotFound - Cookbook hostname not found.  
That kinda makes sense though, because base\_role doesn't have a Berksfile  
tied to it, so how would my chef run know where to get those cookbooks from?

On Mon, Sep 15, 2014 at 6:37 PM, Mark Harrison [mark@mivok.net](mailto:mark@mivok.net) wrote:

> > Now I go back to the mycompany-jenkins metadata.rb file and start adding  
> > more depends lines for hostname, openssh, fail2ban, postfix, java, and  
> > maven. Even though the mycompany-jenkins cookbook doesn't have anything  
> > in  
> > it yet, it depends on all these things because of the role. But the role  
> > doesn't even live inside the cookbook, why should the cookbook have to  
> > declare all those dependencies.
> 
> This seems to be the source of your confusion, and your question is  
> valid. Why _do_ you have to declare all of these unrelated  
> dependencies inside the mycompany-jenkins cookbook? If I'm  
> understanding you correctly, you can leave out hostname, openssh,  
> fail2ban etc from the metadata.rb of mycompany-jenkins and just leave  
> them in the run list of your base role, and things will just work. You  
> add your base role (or the mycompany\_jenkins role, which has the base  
> role in its run list) to your node's run list, and chef will pull in  
> the relevant cookbooks during the chef run.
> 
> Now, you still need to make sure these cookbooks (hostname, openssh  
> and so on) get onto the chef server somehow, and I suspect this is  
> where your desire to put the cookbooks in an unrelated metadata.rb  
> stems from. One option (and the way things have been done in the past)  
> is to put these cookbooks in your chef repository and use knife  
> cookbook upload (or knife upload) to get them on the server. However,  
> it can be tricky to manage and update a repository like that, and this  
> is where berkshelf can help. To make use of berkshelf, you create a  
> Berksfile in the root of your chef repository, and add your cookbooks  
> to that file, then you can use berks install, berks update and berks  
> upload to get your cookbooks onto the server without inventing fake  
> dependencies.
> 
> None of the above precludes you using roles, or eschewing roles  
> altogether. There are some good reasons, mentioned by others in this  
> thread, for using role cookbooks, but you don't have to let your  
> current problem dictate that, and you will probably be perfectly happy  
> to continue to use roles in your repository.

---

<div class="post-metadata">

**Author:** ![Mark\_Harrison1](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/mark_harrison1/32/249_2.png) [@Mark\_Harrison1](https://discourse.chef.io/u/Mark_Harrison1)\
**Post date:** [September 16, 2014, 2:26pm UTC](https://discourse.chef.io/t/should-i-be-using-roles/5723/14 "2014-09-16T14:26:24Z")

</div>

Hi Greg, that makes more sense after your explanation. Depending on  
how you get the cookbooks vendored into the VM (I'm assuming some  
variant on manually running 'berks vendor'), using a 'global'  
Berksfile might work for you. If you decide to try this out, you would  
do something like the following in your Berksfile, which would be  
outside of any specific cookbook (probably at the root of your chef  
repository):

source "[https://supermarket.getchef.com](https://supermarket.getchef.com)"

# Internal/local cookbooks

cookbook "mycompany-jenkins", "\>= 0.0.0", { :path =\>  
"./cookbooks/mycompany-jenkins" }

# Supermarket cookbooks

cookbook "openssh", "~\> 1.2.0" # Put whatever version you need here  
cookbook "...", "~\> ..." # Add the rest of your dependencies here

On Tue, Sep 16, 2014 at 4:48 AM, Greg Barker [fletch@fletchowns.net](mailto:fletch@fletchowns.net) wrote:

> Thank you for all the feedback. Very helpful to hear all these different  
> perspectives on the matter.
> 
> Regarding Mark's comments, perhaps the problem is that I am not using knife  
> or chef server yet, this is just using a Vagrantfile & Berksfile that live  
> in the mycompany-jenkins cookbook. If I don't include the dependencies of  
> base\_role in the metadata.rb for the mycompany-jenkins cookbook, berkshelf  
> does not make vendor the dependency cookbooks into the VM and my run fails  
> with: Chef::Exceptions::CookbookNotFound - Cookbook hostname not found. That  
> kinda makes sense though, because base\_role doesn't have a Berksfile tied to  
> it, so how would my chef run know where to get those cookbooks from?
> 
> On Mon, Sep 15, 2014 at 6:37 PM, Mark Harrison [mark@mivok.net](mailto:mark@mivok.net) wrote:
> 
> > > Now I go back to the mycompany-jenkins metadata.rb file and start adding  
> > > more depends lines for hostname, openssh, fail2ban, postfix, java, and  
> > > maven. Even though the mycompany-jenkins cookbook doesn't have anything  
> > > in  
> > > it yet, it depends on all these things because of the role. But the role  
> > > doesn't even live inside the cookbook, why should the cookbook have to  
> > > declare all those dependencies.
> > 
> > This seems to be the source of your confusion, and your question is  
> > valid. Why _do_ you have to declare all of these unrelated  
> > dependencies inside the mycompany-jenkins cookbook? If I'm  
> > understanding you correctly, you can leave out hostname, openssh,  
> > fail2ban etc from the metadata.rb of mycompany-jenkins and just leave  
> > them in the run list of your base role, and things will just work. You  
> > add your base role (or the mycompany\_jenkins role, which has the base  
> > role in its run list) to your node's run list, and chef will pull in  
> > the relevant cookbooks during the chef run.
> > 
> > Now, you still need to make sure these cookbooks (hostname, openssh  
> > and so on) get onto the chef server somehow, and I suspect this is  
> > where your desire to put the cookbooks in an unrelated metadata.rb  
> > stems from. One option (and the way things have been done in the past)  
> > is to put these cookbooks in your chef repository and use knife  
> > cookbook upload (or knife upload) to get them on the server. However,  
> > it can be tricky to manage and update a repository like that, and this  
> > is where berkshelf can help. To make use of berkshelf, you create a  
> > Berksfile in the root of your chef repository, and add your cookbooks  
> > to that file, then you can use berks install, berks update and berks  
> > upload to get your cookbooks onto the server without inventing fake  
> > dependencies.
> > 
> > None of the above precludes you using roles, or eschewing roles  
> > altogether. There are some good reasons, mentioned by others in this  
> > thread, for using role cookbooks, but you don't have to let your  
> > current problem dictate that, and you will probably be perfectly happy  
> > to continue to use roles in your repository.

---

<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:** [September 17, 2014, 3:25pm UTC](https://discourse.chef.io/t/should-i-be-using-roles/5723/15 "2014-09-17T15:25:50Z")

</div>

If you are using Vagrant, and you decide to go the role/wrapper cookbook  
way (rather than using roles), then this might be helpful too:

> **[GitHub - tknerr/vagrant-toplevel-cookbooks: downloads and installs the...](https://github.com/tknerr/vagrant-toplevel-cookbooks)**
>
> downloads and installs the per-node top-level cookbooks in chef-solo based infrastructures - GitHub - tknerr/vagrant-toplevel-cookbooks: downloads and installs the per-node top-level cookbooks in c...

This pattern works well for me as long as versionable (and  
dependency-manageable) roles are not there yet.

HTH, Torben  
Am 16.09.2014 02:36 schrieb "Lamont Granquist" [lamont@opscode.com](mailto:lamont@opscode.com):

> We're likely to tell you to use roles. If you wind up going the role  
> cookbook route and wind up in with problems with computed attributes, we'll  
> tell you to put that attribute in a role. We recognize that roles have a  
> weakness right now which is that they are not versioned. In the future  
> they're going to be compiled into the policyfile object that gets shipped  
> up to the server and defines how a given node in a given environment  
> behaves.
> 
> We'll almost certainly continue to support role-less deployments, but we  
> won't encourage that because the computed attribute problem is always going  
> to be waiting for people who ditch roles entirely. People who do ditch  
> roles and wind up with the computed attribute problem can continue to try  
> to work around that problem by pushing loading attributes into recipe code,  
> but that goes against best practice. We fixed attribute loading in Chef 11  
> so that people could set attributes deterministically in attribute files  
> with the intent that people would set attributes in roles and attribute  
> files and stop setting them in recipe code (where compile/converge mode  
> issues usually troll them hard). We can't stop people from going that  
> route, but when people wind up leaving behind them a mess of attribute  
> mangling code directly in their recipes we also can't rescue whoever winds  
> up maintaining that.
> 
> There are ways to use setting attributes in recipes that are sane (e.g. to  
> set an attribute saying you did a thing or found a thing and then letting  
> `knife node show` or `knife node search` look for it later), but if you are  
> setting attributes in recipe code and then consuming those attributes  
> later, it is almost always better to push those attributes into attributes  
> files or roles.
> 
> Still you can put roles on a huge diet. You can have roles that include  
> nothing more than a role cookbook. All the attribute setting can be moved  
> to the role cookbook and the run\_list for the role can be put into  
> include\_recipe statements in the default recipe of the role\_cookbook. When  
> you do this, you should be aware that you need one cookbook per every role,  
> you can't have a single role cookbook with all your roles in it, because  
> all of your attribute files will be parsed irregardless of if that role is  
> in the run-list. This leads to a lot of cookbooks, and if you are doing  
> one-git-repo-per-cookbook (per The Berkshelf Way) then you will have a  
> _lot_ of repos -- start budgeting for 50-100 or more for a  
> small-medium-business size deployment.
> 
> So, roles will not be going away, they should be getting fixed and will be  
> more useful in the future.
> 
> On Mon Sep 15 17:15:05 2014, AJ Christensen wrote:
> 
> > Yo,
> > 
> > Forgive my reply-all!
> > 
> > Roles are fine, use whatever you like. I use them all the time! They're  
> > awesome.
> > 
> > If you don't use roles you'll end up half ass inventing them with  
> > application/library/wrapper shenanigan cookbooks, or other external  
> > stuff -- You could put run lists in a custom API, Consul, or etcd, for  
> > example.
> > 
> > I semi-expect Chef to offer some more guidance officially soon with  
> > regard to version-able policy representing the cookbooks, attributes,  
> > version locks and execution order.
> > 
> > Chef-RFC RFC019 [0] is worth looking at regarding workflows and the  
> > ChefDK, "the berkshelf way".
> > 
> > I would also urge you to read Dan's proposal regarding Arbitrary  
> > cookbook identifiers which is used for his (experimental? prototype?)  
> > Policyfile implementation. It's the way I hope we all choose to  
> > proceed, personally. [1]
> > 
> > regards,
> > 
> > --aj (fujin)
> > 
> > [0] [https://github.com/opscode/chef-rfc/blob/](https://github.com/opscode/chef-rfc/blob/)  
> > 6a239ff5dc223290d4488d76fadaeeb6d14f5ab1/rfc019-chef-workflows.md  
> > [1] [Arbitrary cookbook identifiers by danielsdeleo · Pull Request #20 · chef-boneyard/chef-rfc · GitHub](https://github.com/opscode/chef-rfc/pull/20)
> > 
> > On Tue, Sep 16, 2014 at 8:20 AM, Greg Barker [fletch@fletchowns.net](mailto:fletch@fletchowns.net)  
> > wrote:
> > 
> > > After googling around and reading various blog posts about roles, I'm  
> > > still  
> > > not sure if I should be using them. Since I'm new to chef, I wanted to  
> > > describe my line of thinking and hear if maybe I'm going about things the  
> > > wrong way.
> > > 
> > > There are certain things I think might be the same on all my servers, so  
> > > I  
> > > created a base\_role.rb. It's fairly simple: specifies  
> > > set\_fqdn=\*.mycompany.com, some openssh & postfix attributes, and a  
> > > run\_list  
> > > of hostname, openssh, fail2ban, and postfix.
> > > 
> > > So now I want to spin up a jenkins server. I see there is a popular  
> > > community cookbook with some LWRPs that I'll probably use, so I run  
> > > `berks cookbook mycompany-jenkins` to create my jenkins cookbook and add  
> > > "depends  
> > > 'jenkins'" to the metadata.rb file. But I also need the stuff from my  
> > > base\_role on the jenkins server, so I create a new role,  
> > > mycompany\_jenkins.rb. Inside that role I specify some attributes for the  
> > > java version, and the run\_list is role[base\_role], java, maven, jenkins,  
> > > and  
> > > mycompany-jenkins. Or maybe the attributes I specified in the role should  
> > > actually be in the mycompany-jenkins cookbook default attributes?
> > > 
> > > Now I go back to the mycompany-jenkins metadata.rb file and start adding  
> > > more depends lines for hostname, openssh, fail2ban, postfix, java, and  
> > > maven. Even though the mycompany-jenkins cookbook doesn't have anything  
> > > in  
> > > it yet, it depends on all these things because of the role. But the role  
> > > doesn't even live inside the cookbook, why should the cookbook have to  
> > > declare all those dependencies. Now I'm thinking that maybe my base\_role  
> > > should be a recipe instead? Then berks could figure out all those  
> > > dependencies for me. Or should the run\_list I put in the rule actually  
> > > be a  
> > > couple of include\_recipe lines in my default.rb? That would make all the  
> > > depends lines in the metadata make more sense.
> > > 
> > > The 2nd google result for "chef roles" is this article that states  
> > > versioned  
> > > roles are likely coming with Chef 12. I was thinking maybe that is  
> > > something  
> > > that will help me here. So I googled "chef 12 versioned roles" and it  
> > > led me  
> > > to CHEF-4837. It didn't really add much clarity though, I am still  
> > > confused  
> > > where the discussion ends and it doesn't seem to pick up on github.
> > > 
> > > At any rate, hopefully this describes some of my confusion with the use  
> > > of  
> > > roles. Please help steer me in the right direction.
> > > 
> > > Thanks in advance!

---

<div class="post-metadata">

**Author:** ![Olivier\_Bazoud](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/olivier_bazoud/32/242_2.png) [@Olivier\_Bazoud](https://discourse.chef.io/u/Olivier_Bazoud)\
**Post date:** [September 25, 2014, 1:15pm UTC](https://discourse.chef.io/t/should-i-be-using-roles/5723/16 "2014-09-25T13:15:04Z")

</div>

Hi,

FYI Roles can be tested with ChefSpec.

> **[GitHub - chefspec/chefspec: Write RSpec examples and generate coverage...](https://github.com/chefspec/chefspec#testing-roles)**
>
> Write RSpec examples and generate coverage reports for Chef recipes! - GitHub - chefspec/chefspec: Write RSpec examples and generate coverage reports for Chef recipes!

Olivier.

On Tue, Sep 16, 2014 at 6:26 AM, Eric G. Wolfe [eric.wolfe@gmail.com](mailto:eric.wolfe@gmail.com) wrote:

> -----BEGIN PGP SIGNED MESSAGE-----  
> Hash: SHA1
> 
> I believe the reasoning behind this doesn't really end at versioning,  
> and that is too much of an oversimplification to be useful to the  
> casual reader.
> 
> Roles are just data. You can in some cases screw up your data, and  
> since the data is not "software" it makes it harder to test those data  
> inputs on their own.
> 
> If you do a role, or wrapper, cookbook. That cookbook, or even a  
> recipe within a cookbook is still a role. The cookbook happens to  
> take the shape and properties of software. Software  
> (cookbooks/recipes) can be easily tested and controlled with the tools  
> we have like Jenkins, Kitchen, Foodcritic, and Chefspec. If it is  
> one's goal to set up a delivery pipeline with quality controlled  
> (tested) software with released artifacts, then cookbooks make more  
> sense than pure data roles. Its just easier that way.
> 
> However, we are still doing data-driven configuration with either  
> model. There is nothing inherently wrong with using roles. Its not a  
> bad starting point for discovery of what could work for an  
> organization. For some people roles are good enough, and they might  
> have only a few static edge cases which can be covered by roles and  
> commodity cookbooks alone.
> 
> Adding versions to roles, does not solve a quality control problem  
> with those data objects. That alone, is a superficial reason to avoid  
> them.
> 
> Eric G. Wolfe  
> email: [eric.wolfe@cyclecomputing.com](mailto:eric.wolfe@cyclecomputing.com)  
> cell: 304.942.3970  
> twitter: @atomic\_penguin
> 
> Cycle Computing  
> Leader in Utility HPC Software
> 
> [http://www.cyclecomputing.com](http://www.cyclecomputing.com)  
> twitter: @cyclecomputing
> 
> On 09/15/2014 07:47 PM, Kenneth Barry wrote:
> 
> > There is a strong argument for not using roles all together.
> > 
> > One of the main arguments is that they are not versioned. Instead,  
> > going with more, and more granular cookbooks (Which are versioned).  
> > Not an expert on it, but this is a core philosophy or the  
> > "BerkShelf" way.
> 
> -----BEGIN PGP SIGNATURE-----  
> Version: GnuPG v1
> 
> iQEcBAEBAgAGBQJUF7vcAAoJEIu8EfDNV4biFbYH/Ag0UIm3GLPnzs4gW8uSEYj7  
> SfHFkOAScHtJTrVV9SfFBAEpIiK3sgBDSDlhboc6Lqmdw3BNbL9elNMvKsqrgxqq  
> sp6iuNAPJNgCJJ5aDfttFncer0+XVrctiUSIOipQOU2a71iz79O3Wl8yVk7Ps5MY  
> 6Ar63703u/na3Rfb3mjMeH7MVXJsKoVQOegbGwtSQyzyzwFUsGsb8KyrLt/O3Oa4  
> eovnnjlejnoVMau05tOfZkwetQFWRkExE0GEaVODVV5FmyBc1b3SnjQ/OOCygQ0a  
> 4lJibYCNdtg0dmj06aBYqpwH/r7xUDNLamozq62hWsaWnk6ZCstAgyn9D+nkqHw=  
> =Qmhx  
> -----END PGP SIGNATURE-----