[chef] Re: Should I be using roles?

[Michael deMan < >]

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, <specialty>.  Where <specialty> 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 <specialty> 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 <specialty> 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 < "> > 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 < " target="_blank"> > 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 < " target="_blank"> > 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

On Mon, Sep 15, 2014 at 1:20 PM, Greg Barker < " target="_blank"> > 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