Roles and Versioning

Chef Infra (archive)
1

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

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

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

Thanks,
Kevin Christen

2

Kevin,

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

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

Cheers,
Jay

On Tue, Nov 20, 2012 at 1:31 PM, Kevin Christen kevin.christen@gmail.comwrote:

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

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

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

Thanks,
Kevin Christen

3

On Wed, Nov 21, 2012 at 5:31 AM, Kevin Christen kevin.christen@gmail.comwrote:

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

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

[1]
http://realityforge.org/code/2012/11/19/role-cookbooks-and-wrapper-cookbooks.html

Cheers,

Peter Donald

4

hey Kevin,

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

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

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

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

On Tue, Nov 20, 2012 at 7:31 PM, Kevin Christen kevin.christen@gmail.comwrote:

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

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

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

Thanks,
Kevin Christen

5

Am 20.11.2012 20:09 schrieb "Bryan Berry" bryan.berry@gmail.com:

hey Kevin,

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

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

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

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

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

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

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

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

Version the role through its name. In other words, leave "foo_host"
alone and create a "foo_host_1" role with both recipes in its run_list.
Run separate versions of chef server for each environment, as
mentioned here. Update the role in only those servers who's environment
will pick up the latest version of the cookbook.
Don't use a role for this purpose. Instead, define a separate, versioned
"wrapper" cookbook as described by Bryan Berry here.
Is there a community consensus on how to deal with this situation?

Thanks,
Kevin Christen

6

Am 20.11.2012 20:09 schrieb "Bryan Berry" bryan.berry@gmail.com:

hey Kevin,

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

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

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

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

...and I totally second that. Hats up! :slight_smile:

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

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

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

Version the role through its name. In other words, leave "foo_host"
alone and create a "foo_host_1" role with both recipes in its run_list.
Run separate versions of chef server for each environment, as
mentioned here. Update the role in only those servers who's environment
will pick up the latest version of the cookbook.
Don't use a role for this purpose. Instead, define a separate, versioned
"wrapper" cookbook as described by Bryan Berry here.
Is there a community consensus on how to deal with this situation?

Thanks,
Kevin Christen

7

So you are saying that you don't like the option of using any
default_attributes nor override_attributes in roles?

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

Am 20.11.2012 20:09 schrieb "Bryan Berry" bryan.berry@gmail.com:

hey Kevin,

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

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

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

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

...and I totally second that. Hats up! :slight_smile:

On Tue, Nov 20, 2012 at 7:31 PM, Kevin Christen <
kevin.christen@gmail.com> wrote:

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

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

Version the role through its name. In other words, leave "foo_host"
alone and create a "foo_host_1" role with both recipes in its run_list.
Run separate versions of chef server for each environment, as
mentioned here. Update the role in only those servers who's environment
will pick up the latest version of the cookbook.
Don't use a role for this purpose. Instead, define a separate,
versioned "wrapper" cookbook as described by Bryan Berry here.
Is there a community consensus on how to deal with this situation?

Thanks,
Kevin Christen

8

Jay,

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

Thanks,
Kevin Christen

On Tue, Nov 20, 2012 at 12:47 PM, Jay Feldblum y_feldblum@yahoo.com wrote:

Kevin,

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

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

Cheers,
Jay

On Tue, Nov 20, 2012 at 1:31 PM, Kevin Christen kevin.christen@gmail.comwrote:

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

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

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

Thanks,
Kevin Christen

9

Kevin,

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

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

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

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

Cheers,
Jay

On Wed, Nov 21, 2012 at 10:25 AM, Kevin Christen
kevin.christen@gmail.comwrote:

Jay,

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

Thanks,
Kevin Christen

On Tue, Nov 20, 2012 at 12:47 PM, Jay Feldblum y_feldblum@yahoo.comwrote:

Kevin,

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

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

Cheers,
Jay

10

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

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

Kevin,

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

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

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

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

Cheers,
Jay

On Wed, Nov 21, 2012 at 10:25 AM, Kevin Christen <kevin.christen@gmail.commailto:kevin.christen@gmail.com> wrote:
Jay,

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

Thanks,
Kevin Christen

On Tue, Nov 20, 2012 at 12:47 PM, Jay Feldblum <y_feldblum@yahoo.commailto:y_feldblum@yahoo.com> wrote:
Kevin,

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

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

Cheers,
Jay

11

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

-M

On Wed, Nov 21, 2012 at 12:50 PM, Tim Smith Tim.Smith@webtrends.com wrote:

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

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

Kevin,

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

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

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

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

Cheers,
Jay

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

Jay,

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

Thanks,
Kevin Christen

On Tue, Nov 20, 2012 at 12:47 PM, Jay Feldblum y_feldblum@yahoo.com
wrote:

Kevin,

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

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

Cheers,
Jay

12

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

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

On 11/21/12 9:54 AM, "Mike" miketheman@gmail.com wrote:

Tim:
For environments specific run lists, use Environment Run Lists.
http://wiki.opscode.com/display/chef/Environments#Environments-PerEnvironm
entRunListsinRoles

-M

On Wed, Nov 21, 2012 at 12:50 PM, Tim Smith Tim.Smith@webtrends.com
wrote:

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

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

Kevin,

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

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

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

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

Cheers,
Jay

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

Jay,

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

Thanks,
Kevin Christen

On Tue, Nov 20, 2012 at 12:47 PM, Jay Feldblum y_feldblum@yahoo.com
wrote:

Kevin,

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

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

Cheers,
Jay

13

Tim,

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

Cheers,
Jay

On Wed, Nov 21, 2012 at 1:08 PM, Tim Smith Tim.Smith@webtrends.com wrote:

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

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

On 11/21/12 9:54 AM, "Mike" miketheman@gmail.com wrote:

Tim:
For environments specific run lists, use Environment Run Lists.

http://wiki.opscode.com/display/chef/Environments#Environments-PerEnvironm

entRunListsinRoles

-M

On Wed, Nov 21, 2012 at 12:50 PM, Tim Smith Tim.Smith@webtrends.com
wrote:

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

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

Kevin,

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

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

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

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

Cheers,
Jay

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

Jay,

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

Thanks,
Kevin Christen

On Tue, Nov 20, 2012 at 12:47 PM, Jay Feldblum y_feldblum@yahoo.com
wrote:

Kevin,

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

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

Cheers,
Jay

14

Kevin,

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

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

Michael Glenney
Sent from my iPhone

On Nov 21, 2012, at 8:25 AM, Kevin Christen kevin.christen@gmail.com wrote:

Jay,

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

Thanks,
Kevin Christen

On Tue, Nov 20, 2012 at 12:47 PM, Jay Feldblum y_feldblum@yahoo.com wrote:

Kevin,

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

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

Cheers,
Jay

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

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

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

Version the role through its name. In other words, leave "foo_host" alone and create a "foo_host_1" role with both recipes in its run_list.
Run separate versions of chef server for each environment, as mentioned here. Update the role in only those servers who's environment will pick up the latest version of the cookbook.
Don't use a role for this purpose. Instead, define a separate, versioned "wrapper" cookbook as described by Bryan Berry here.
Is there a community consensus on how to deal with this situation?

Thanks,
Kevin Christen

15

On Nov 21, 2012, at 12:50 PM, Tim Smith Tim.Smith@Webtrends.com wrote:

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

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

Have a listen to this:

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

--Brian

16

Hey Brian,

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

Jamie Winsor
@resetexistence

On Nov 26, 2012, at 8:35 PM, Brian Akins brian@akins.org wrote:

On Nov 21, 2012, at 12:50 PM, Tim Smith Tim.Smith@Webtrends.com wrote:

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

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

Have a listen to this:

Jamie Winsor and Michael Ivey Skool us on Berkshelf - Food Fight

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

--Brian