Should I be using roles?


#1

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
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.
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!


#2

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
2407 S Congress Ave Ste E-350
Austin, TX 78704
United States

From: Greg Barker fletch@fletchowns.net
To: 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, 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!


#3

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 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
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. 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!


#4

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
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 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
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. 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


#5

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

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 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
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. 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


#6

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

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 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
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. 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


#7

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
[1] https://github.com/opscode/chef-rfc/pull/20

On Tue, Sep 16, 2014 at 8:20 AM, Greg Barker 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!


#8

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


#9

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
[1] 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:

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 (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


#10

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
[1] https://github.com/opscode/chef-rfc/pull/20

On Tue, Sep 16, 2014 at 8:20 AM, Greg Barker 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!


#11

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.


#12

-----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
cell: 304.942.3970
twitter: @atomic_penguin

Cycle Computing
Leader in Utility HPC Software


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


#13

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 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.


#14

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

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 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 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.


#15

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:

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:

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
[1] https://github.com/opscode/chef-rfc/pull/20

On Tue, Sep 16, 2014 at 8:20 AM, Greg Barker 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!


#16

Hi,

FYI Roles can be tested with ChefSpec.

Olivier.

On Tue, Sep 16, 2014 at 6:26 AM, Eric G. Wolfe 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
cell: 304.942.3970
twitter: @atomic_penguin

Cycle Computing
Leader in Utility HPC Software

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