A few months ago there was some discussion about using cookbooks as containers in place of roles. This started with a blog post that advocated always using cookbooks in place of roles, as I recall (though I can’t seem to find it at the moment). Some discussions at work have got me to thinking this might be a useful thing in some cases, so I’m wondering how many of you are actually doing this and what you have found the pros/cons of this approach to be.
Thanks in advance
–
Larry Wright
This is the crux of "The Berkshelf Way": www.youtube.com/watch?v=hYt0E84kYUI
On Tue, Jun 11, 2013 at 3:31 PM, Larry Wright larrywright@gmail.com wrote:
A few months ago there was some discussion about using cookbooks as
containers in place of roles. This started with a blog post that advocated
always using cookbooks in place of roles, as I recall (though I can't seem
to find it at the moment). Some discussions at work have got me to thinking
this might be a useful thing in some cases, so I'm wondering how many of
you are actually doing this and what you have found the pros/cons of this
approach to be.Thanks in advance
--
Larry Wright
this?
i use a combination of both, if i can achieve my customizations just by
means of attributes and aggregating recipes, i always prefer to use roles.
Its cleaner, by design roles does not allow any logic except attributes and
a run list. If i need anything more than this, i use cookbooks/recipes.
On Tue, Jun 11, 2013 at 12:31 PM, Larry Wright larrywright@gmail.comwrote:
A few months ago there was some discussion about using cookbooks as
containers in place of roles. This started with a blog post that advocated
always using cookbooks in place of roles, as I recall (though I can't seem
to find it at the moment). Some discussions at work have got me to thinking
this might be a useful thing in some cases, so I'm wondering how many of
you are actually doing this and what you have found the pros/cons of this
approach to be.Thanks in advance
--
Larry Wright
The lack of versioning makes the role argument a
non-starter, for me...
On Tue, Jun 11, 2013 at 12:35 PM, Ranjib Dey dey.ranjib@gmail.com wrote:
this?
devopsanywhere: How to Write Reusable Chef Cookbooks, Gangnam Stylei use a combination of both, if i can achieve my customizations just by
means of attributes and aggregating recipes, i always prefer to use roles.
Its cleaner, by design roles does not allow any logic except attributes and
a run list. If i need anything more than this, i use cookbooks/recipes.On Tue, Jun 11, 2013 at 12:31 PM, Larry Wright larrywright@gmail.comwrote:
A few months ago there was some discussion about using cookbooks as
containers in place of roles. This started with a blog post that advocated
always using cookbooks in place of roles, as I recall (though I can't seem
to find it at the moment). Some discussions at work have got me to thinking
this might be a useful thing in some cases, so I'm wondering how many of
you are actually doing this and what you have found the pros/cons of this
approach to be.Thanks in advance
--
Larry Wright
This is what I'm thinking, but I'm curious: what use cases do you have for versioning roles?
Thanks
--
Larry Wright
On Tuesday, June 11, 2013 at 4:19 PM, Bryan Stenson wrote:
The lack of versioning makes the role argument a non-starter, for me...
On Tue, Jun 11, 2013 at 12:35 PM, Ranjib Dey <dey.ranjib@gmail.com (mailto:dey.ranjib@gmail.com)> wrote:
this? devopsanywhere: How to Write Reusable Chef Cookbooks, Gangnam Style
i use a combination of both, if i can achieve my customizations just by means of attributes and aggregating recipes, i always prefer to use roles. Its cleaner, by design roles does not allow any logic except attributes and a run list. If i need anything more than this, i use cookbooks/recipes.
On Tue, Jun 11, 2013 at 12:31 PM, Larry Wright <larrywright@gmail.com (mailto:larrywright@gmail.com)> wrote:
A few months ago there was some discussion about using cookbooks as containers in place of roles. This started with a blog post that advocated always using cookbooks in place of roles, as I recall (though I can't seem to find it at the moment). Some discussions at work have got me to thinking this might be a useful thing in some cases, so I'm wondering how many of you are actually doing this and what you have found the pros/cons of this approach to be.
Thanks in advance
--
Larry Wright
We've moving towards "cookbooks in place of roles". Not being able to
version lock roles is a real problem. Note that if you're currently
relying on the role-level precedence you may need to rethink.
On Tue, Jun 11, 2013 at 12:35 PM, Ranjib Dey dey.ranjib@gmail.com wrote:
this?
devopsanywhere: How to Write Reusable Chef Cookbooks, Gangnam Stylei use a combination of both, if i can achieve my customizations just by
means of attributes and aggregating recipes, i always prefer to use roles.
Its cleaner, by design roles does not allow any logic except attributes and
a run list. If i need anything more than this, i use cookbooks/recipes.On Tue, Jun 11, 2013 at 12:31 PM, Larry Wright larrywright@gmail.comwrote:
A few months ago there was some discussion about using cookbooks as
containers in place of roles. This started with a blog post that advocated
always using cookbooks in place of roles, as I recall (though I can't seem
to find it at the moment). Some discussions at work have got me to thinking
this might be a useful thing in some cases, so I'm wondering how many of
you are actually doing this and what you have found the pros/cons of this
approach to be.Thanks in advance
--
Larry Wright
roles are designed to make the whole system flexible and easy to use.
It really depends on your business requirements and current situation. You
could be in a situation where you're in a team that is slow to adopt new
cultural and workflow changes.
Telling a team in that situation "Ok you need to learn just a bit of ruby
in order to append the resolv.conf settings. By the way since you're
modifying code you need to go through a brand new process before rolling
out to production. Oh and remember how you would test in Dev? yea that's
not going to work anymore because Dev is now Production" Versus. "Here's a
role that's applied to all of our servers, these settings shouldn't ever
really change because that's how roles were designed, but since we'd like
to add another dns server follow the same format that is in this role"
if you're in a team like Riot Games who off the bat know ruby or
development processes then hell ya cookbook all the things!
While beating the dead horse ..they're there for certain use cases and
allowing flexibility. Not everybody is a "devops" ninja. someone on the
food fight show said that.
To really beat the horse dead. Only the person/team implementing chef needs
to use the right ingredients at the right time. You can't take someone
else's ideas and or concepts and apply it to your environment expecting
Nirvana.
With all that said. One needs to take care in using roles. Like cooking
there needs to be a balance of everything in my opinion. Roles really need
to be used as they were designed [0]"A role is a way to define certain
patterns and processes that exist across nodes in a Chef organization as
belonging to a single job function."
It's safe to say that if a new guy comes into my environment who is new to
chef and the culture of devops they can see how my environment looks
without having to dig into the chef recipes one by one.
[0]http://docs.opscode.com/essentials_roles.html
On Tue, Jun 11, 2013 at 5:27 PM, Joshua Miller joshuamiller01@gmail.comwrote:
We've moving towards "cookbooks in place of roles". Not being able to
version lock roles is a real problem. Note that if you're currently
relying on the role-level precedence you may need to rethink.On Tue, Jun 11, 2013 at 12:35 PM, Ranjib Dey dey.ranjib@gmail.com wrote:
this?
devopsanywhere: How to Write Reusable Chef Cookbooks, Gangnam Stylei use a combination of both, if i can achieve my customizations just by
means of attributes and aggregating recipes, i always prefer to use roles.
Its cleaner, by design roles does not allow any logic except attributes and
a run list. If i need anything more than this, i use cookbooks/recipes.On Tue, Jun 11, 2013 at 12:31 PM, Larry Wright larrywright@gmail.comwrote:
A few months ago there was some discussion about using cookbooks as
containers in place of roles. This started with a blog post that advocated
always using cookbooks in place of roles, as I recall (though I can't seem
to find it at the moment). Some discussions at work have got me to thinking
this might be a useful thing in some cases, so I'm wondering how many of
you are actually doing this and what you have found the pros/cons of this
approach to be.Thanks in advance
--
Larry Wright
--
Elvin Abordo
Mobile: (845) 475-8744
/sigh proofreading will be the end of me. I was going to mention something
about the food fight show, but the quote escaped me.
On Tue, Jun 11, 2013 at 6:02 PM, Elvin Abordo elvin159@gmail.com wrote:
roles are designed to make the whole system flexible and easy to use.
It really depends on your business requirements and current situation. You
could be in a situation where you're in a team that is slow to adopt new
cultural and workflow changes.Telling a team in that situation "Ok you need to learn just a bit of ruby
in order to append the resolv.conf settings. By the way since you're
modifying code you need to go through a brand new process before rolling
out to production. Oh and remember how you would test in Dev? yea that's
not going to work anymore because Dev is now Production" Versus. "Here's a
role that's applied to all of our servers, these settings shouldn't ever
really change because that's how roles were designed, but since we'd like
to add another dns server follow the same format that is in this role"if you're in a team like Riot Games who off the bat know ruby or
development processes then hell ya cookbook all the things!While beating the dead horse ..they're there for certain use cases and
allowing flexibility. Not everybody is a "devops" ninja. someone on the
food fight show said that.To really beat the horse dead. Only the person/team implementing chef
needs to use the right ingredients at the right time. You can't take
someone else's ideas and or concepts and apply it to your environment
expecting Nirvana.With all that said. One needs to take care in using roles. Like cooking
there needs to be a balance of everything in my opinion. Roles really need
to be used as they were designed [0]"A role is a way to define certain
patterns and processes that exist across nodes in a Chef organization as
belonging to a single job function."It's safe to say that if a new guy comes into my environment who is new to
chef and the culture of devops they can see how my environment looks
without having to dig into the chef recipes one by one.[0]http://docs.opscode.com/essentials_roles.html
On Tue, Jun 11, 2013 at 5:27 PM, Joshua Miller joshuamiller01@gmail.comwrote:
We've moving towards "cookbooks in place of roles". Not being able to
version lock roles is a real problem. Note that if you're currently
relying on the role-level precedence you may need to rethink.On Tue, Jun 11, 2013 at 12:35 PM, Ranjib Dey dey.ranjib@gmail.comwrote:
this?
devopsanywhere: How to Write Reusable Chef Cookbooks, Gangnam Stylei use a combination of both, if i can achieve my customizations just by
means of attributes and aggregating recipes, i always prefer to use roles.
Its cleaner, by design roles does not allow any logic except attributes and
a run list. If i need anything more than this, i use cookbooks/recipes.On Tue, Jun 11, 2013 at 12:31 PM, Larry Wright larrywright@gmail.comwrote:
A few months ago there was some discussion about using cookbooks as
containers in place of roles. This started with a blog post that advocated
always using cookbooks in place of roles, as I recall (though I can't seem
to find it at the moment). Some discussions at work have got me to thinking
this might be a useful thing in some cases, so I'm wondering how many of
you are actually doing this and what you have found the pros/cons of this
approach to be.Thanks in advance
--
Larry Wright--
Elvin Abordo
Mobile: (845) 475-8744
--
Elvin Abordo
Mobile: (845) 475-8744
We use roles when we can and cookbooks when run-time is necessary.
However we separate our prod chef server from the rest so the role update
has to go through a release procedure. This gives us the best of both world
with the drawback of having 2 chef servers.
On Jun 12, 2013 12:05 AM, "Elvin Abordo" elvin159@gmail.com wrote:
/sigh proofreading will be the end of me. I was going to mention something
about the food fight show, but the quote escaped me.On Tue, Jun 11, 2013 at 6:02 PM, Elvin Abordo elvin159@gmail.com wrote:
roles are designed to make the whole system flexible and easy to use.
It really depends on your business requirements and current situation.
You could be in a situation where you're in a team that is slow to adopt
new cultural and workflow changes.Telling a team in that situation "Ok you need to learn just a bit of
ruby in order to append the resolv.conf settings. By the way since you're
modifying code you need to go through a brand new process before rolling
out to production. Oh and remember how you would test in Dev? yea that's
not going to work anymore because Dev is now Production" Versus. "Here's a
role that's applied to all of our servers, these settings shouldn't ever
really change because that's how roles were designed, but since we'd like
to add another dns server follow the same format that is in this role"if you're in a team like Riot Games who off the bat know ruby or
development processes then hell ya cookbook all the things!While beating the dead horse ..they're there for certain use cases and
allowing flexibility. Not everybody is a "devops" ninja. someone on the
food fight show said that.To really beat the horse dead. Only the person/team implementing chef
needs to use the right ingredients at the right time. You can't take
someone else's ideas and or concepts and apply it to your environment
expecting Nirvana.With all that said. One needs to take care in using roles. Like cooking
there needs to be a balance of everything in my opinion. Roles really need
to be used as they were designed [0]"A role is a way to define certain
patterns and processes that exist across nodes in a Chef organization
as belonging to a single job function."It's safe to say that if a new guy comes into my environment who is new
to chef and the culture of devops they can see how my environment looks
without having to dig into the chef recipes one by one.[0]http://docs.opscode.com/essentials_roles.html
On Tue, Jun 11, 2013 at 5:27 PM, Joshua Miller joshuamiller01@gmail.comwrote:
We've moving towards "cookbooks in place of roles". Not being able to
version lock roles is a real problem. Note that if you're currently
relying on the role-level precedence you may need to rethink.On Tue, Jun 11, 2013 at 12:35 PM, Ranjib Dey dey.ranjib@gmail.comwrote:
this?
devopsanywhere: How to Write Reusable Chef Cookbooks, Gangnam Stylei use a combination of both, if i can achieve my customizations just by
means of attributes and aggregating recipes, i always prefer to use roles.
Its cleaner, by design roles does not allow any logic except attributes and
a run list. If i need anything more than this, i use cookbooks/recipes.On Tue, Jun 11, 2013 at 12:31 PM, Larry Wright larrywright@gmail.comwrote:
A few months ago there was some discussion about using cookbooks as
containers in place of roles. This started with a blog post that advocated
always using cookbooks in place of roles, as I recall (though I can't seem
to find it at the moment). Some discussions at work have got me to thinking
this might be a useful thing in some cases, so I'm wondering how many of
you are actually doing this and what you have found the pros/cons of this
approach to be.Thanks in advance
--
Larry Wright--
Elvin Abordo
Mobile: (845) 475-8744--
Elvin Abordo
Mobile: (845) 475-8744
While we are huge fans of the control that wrapper cookbooks gives us in
production, we are rethinking their uses in other “environments” like dev
because the learning curve can be steep.
Hey Elvin,
With the exception of my 8 person team at Riot, nobody else really knows Ruby. It's been quite a challenge for us over the last two years to create a workflow and supporting tools to enable non-Ruby and non-engineering types to leverage Chef properly.
The number one way that we were able to empower our software engineers and operations folks was to focus on reducing complexity.
The second most important thing that we've done is to create a clean room for people to live in by prescribing and documenting a workflow for people to follow.
There's just no reason to need to explain anything past a cookbook to an engineer or an operator. This cookbook is for a specific component in your infrastructure and it contains a README. This README contains instructions for which recipes to place on a machine to turn it into the thing that you want it to become (this is where a Role COULD have come in). And the operator/engineer uploads this cookbook into their Chef server and locks their environment to use just the version of the cookbook that you gave them. Bonus points because you remembered to explicitly state your dependencies and gave them some nice version constraints in your cookbooks' metadata.
We have some still non-open sourced (soon to be) tooling here that assists this process even more, but this is a pretty good summary of the generic workflow we built off of. With the addition of the berks apply command (new in 2.0) you also could be "promoting" the state of entire environments throughout some sort of release pipeline.
This works for us, but I think it would work for you too.
--
Jamie Winsor
@resetexistence
On Tuesday, June 11, 2013 at 3:05 PM, Elvin Abordo wrote:
/sigh proofreading will be the end of me. I was going to mention something about the food fight show, but the quote escaped me.
On Tue, Jun 11, 2013 at 6:02 PM, Elvin Abordo <elvin159@gmail.com (mailto:elvin159@gmail.com)> wrote:
roles are designed to make the whole system flexible and easy to use.
It really depends on your business requirements and current situation. You could be in a situation where you're in a team that is slow to adopt new cultural and workflow changes.
Telling a team in that situation "Ok you need to learn just a bit of ruby in order to append the resolv.conf settings. By the way since you're modifying code you need to go through a brand new process before rolling out to production. Oh and remember how you would test in Dev? yea that's not going to work anymore because Dev is now Production" Versus. "Here's a role that's applied to all of our servers, these settings shouldn't ever really change because that's how roles were designed, but since we'd like to add another dns server follow the same format that is in this role"
if you're in a team like Riot Games who off the bat know ruby or development processes then hell ya cookbook all the things!
While beating the dead horse ..they're there for certain use cases and allowing flexibility. Not everybody is a "devops" ninja. someone on the food fight show said that.
To really beat the horse dead. Only the person/team implementing chef needs to use the right ingredients at the right time. You can't take someone else's ideas and or concepts and apply it to your environment expecting Nirvana.
With all that said. One needs to take care in using roles. Like cooking there needs to be a balance of everything in my opinion. Roles really need to be used as they were designed [0]"A role is a way to define certain patterns and processes that exist across nodes in a Chef organization as belonging to a single job function."
It's safe to say that if a new guy comes into my environment who is new to chef and the culture of devops they can see how my environment looks without having to dig into the chef recipes one by one.
[0]http://docs.opscode.com/essentials_roles.html
On Tue, Jun 11, 2013 at 5:27 PM, Joshua Miller <joshuamiller01@gmail.com (mailto:joshuamiller01@gmail.com)> wrote:
We've moving towards "cookbooks in place of roles". Not being able to version lock roles is a real problem. Note that if you're currently relying on the role-level precedence you may need to rethink.
On Tue, Jun 11, 2013 at 12:35 PM, Ranjib Dey <dey.ranjib@gmail.com (mailto:dey.ranjib@gmail.com)> wrote:
this? devopsanywhere: How to Write Reusable Chef Cookbooks, Gangnam Style
i use a combination of both, if i can achieve my customizations just by means of attributes and aggregating recipes, i always prefer to use roles. Its cleaner, by design roles does not allow any logic except attributes and a run list. If i need anything more than this, i use cookbooks/recipes.
On Tue, Jun 11, 2013 at 12:31 PM, Larry Wright <larrywright@gmail.com (mailto:larrywright@gmail.com)> wrote:
A few months ago there was some discussion about using cookbooks as containers in place of roles. This started with a blog post that advocated always using cookbooks in place of roles, as I recall (though I can't seem to find it at the moment). Some discussions at work have got me to thinking this might be a useful thing in some cases, so I'm wondering how many of you are actually doing this and what you have found the pros/cons of this approach to be.
Thanks in advance
--
Larry Wright--
Elvin Abordo
Mobile: (845) 475-8744 (tel:%28845%29%20475-8744)--
Elvin Abordo
Mobile: (845) 475-8744
Most definitely i think your suggestions will work out for specifically my developers. The thing with my infrastructure is that we have 3 different teams in the kitchen. Your suggestions will definitely fit in with my developers. As that was our original plan.
The only reason why my infrastructure is the way it is with roles is because the other two teams need to be eased into the concept of everything chef. Without getting into too much details. Asking the difference between a hash and an array would be pulling teeth. So for the other two teams looking at a role file is a bit easier to understand than a full blown recipe that references attributes/default.rb.
Which goes back to my point of "it really depends on the situation". We have documentation in place to distill everything but its been a journey.
Oh and berkshelf rocks 
thank you again.
—
Sent from Mailbox for iPhone
On Tue, Jun 11, 2013 at 6:18 PM, Jamie Winsor jamie@vialstudios.com
wrote:
Hey Elvin,
With the exception of my 8 person team at Riot, nobody else really knows Ruby. It's been quite a challenge for us over the last two years to create a workflow and supporting tools to enable non-Ruby and non-engineering types to leverage Chef properly.
The number one way that we were able to empower our software engineers and operations folks was to focus on reducing complexity.
The second most important thing that we've done is to create a clean room for people to live in by prescribing and documenting a workflow for people to follow.
There's just no reason to need to explain anything past a cookbook to an engineer or an operator. This cookbook is for a specific component in your infrastructure and it contains a README. This README contains instructions for which recipes to place on a machine to turn it into the thing that you want it to become (this is where a Role COULD have come in). And the operator/engineer uploads this cookbook into their Chef server and locks their environment to use just the version of the cookbook that you gave them. Bonus points because you remembered to explicitly state your dependencies and gave them some nice version constraints in your cookbooks' metadata.
We have some still non-open sourced (soon to be) tooling here that assists this process even more, but this is a pretty good summary of the generic workflow we built off of. With the addition of theberks applycommand (new in 2.0) you also could be "promoting" the state of entire environments throughout some sort of release pipeline.
This works for us, but I think it would work for you too.Jamie Winsor
@resetexistence
reset (Jamie Stormbreaker) · GitHub
On Tuesday, June 11, 2013 at 3:05 PM, Elvin Abordo wrote:/sigh proofreading will be the end of me. I was going to mention something about the food fight show, but the quote escaped me.
On Tue, Jun 11, 2013 at 6:02 PM, Elvin Abordo <elvin159@gmail.com (mailto:elvin159@gmail.com)> wrote:
roles are designed to make the whole system flexible and easy to use.
It really depends on your business requirements and current situation. You could be in a situation where you're in a team that is slow to adopt new cultural and workflow changes.
Telling a team in that situation "Ok you need to learn just a bit of ruby in order to append the resolv.conf settings. By the way since you're modifying code you need to go through a brand new process before rolling out to production. Oh and remember how you would test in Dev? yea that's not going to work anymore because Dev is now Production" Versus. "Here's a role that's applied to all of our servers, these settings shouldn't ever really change because that's how roles were designed, but since we'd like to add another dns server follow the same format that is in this role"
if you're in a team like Riot Games who off the bat know ruby or development processes then hell ya cookbook all the things!
While beating the dead horse ..they're there for certain use cases and allowing flexibility. Not everybody is a "devops" ninja. someone on the food fight show said that.
To really beat the horse dead. Only the person/team implementing chef needs to use the right ingredients at the right time. You can't take someone else's ideas and or concepts and apply it to your environment expecting Nirvana.
With all that said. One needs to take care in using roles. Like cooking there needs to be a balance of everything in my opinion. Roles really need to be used as they were designed [0]"A role is a way to define certain patterns and processes that exist across nodes in a Chef organization as belonging to a single job function."
It's safe to say that if a new guy comes into my environment who is new to chef and the culture of devops they can see how my environment looks without having to dig into the chef recipes one by one.
[0]http://docs.opscode.com/essentials_roles.html
On Tue, Jun 11, 2013 at 5:27 PM, Joshua Miller <joshuamiller01@gmail.com (mailto:joshuamiller01@gmail.com)> wrote:
We've moving towards "cookbooks in place of roles". Not being able to version lock roles is a real problem. Note that if you're currently relying on the role-level precedence you may need to rethink.
On Tue, Jun 11, 2013 at 12:35 PM, Ranjib Dey <dey.ranjib@gmail.com (mailto:dey.ranjib@gmail.com)> wrote:
this? devopsanywhere: How to Write Reusable Chef Cookbooks, Gangnam Style
i use a combination of both, if i can achieve my customizations just by means of attributes and aggregating recipes, i always prefer to use roles. Its cleaner, by design roles does not allow any logic except attributes and a run list. If i need anything more than this, i use cookbooks/recipes.
On Tue, Jun 11, 2013 at 12:31 PM, Larry Wright <larrywright@gmail.com (mailto:larrywright@gmail.com)> wrote:
A few months ago there was some discussion about using cookbooks as containers in place of roles. This started with a blog post that advocated always using cookbooks in place of roles, as I recall (though I can't seem to find it at the moment). Some discussions at work have got me to thinking this might be a useful thing in some cases, so I'm wondering how many of you are actually doing this and what you have found the pros/cons of this approach to be.
Thanks in advance
--
Larry Wright--
Elvin Abordo
Mobile: (845) 475-8744 (tel:%28845%29%20475-8744)--
Elvin Abordo
Mobile: (845) 475-8744