Add "url" to depends/metadata?


#1

Would it make sense for us to consider adding the external url info to
metadata ? This way berks/librarian/whisk/whatever tool can operate against
the metadata, and cookbook makers don’t have to worry much about the
specific implementation that users prefer?

Is there a good reason not to do this?


#2

On Nov 15, 2012, at 12:09 AM, Jesse Nelson spheromak@gmail.com wrote:

Would it make sense for us to consider adding the external url info to metadata ? This way berks/librarian/whisk/whatever tool can operate against the metadata, and cookbook makers don’t have to worry much about the specific implementation that users prefer?

I’m assuming you mean the URL to the cookbook itself.

Wouldn’t this end up being a chicken-and-egg problem though? i.e. how is Berkshelf etc. supposed to know what URL to put in the Berksfile without, er, going to a URL to get the cookbook?

Other than that, I see it as harmless.

  • Julian

#3

On Nov 14, 2012, at 9:09 PM, Jesse Nelson wrote:

Would it make sense for us to consider adding the external url info to metadata ? This way berks/librarian/whisk/whatever tool can operate against the metadata, and cookbook makers don’t have to worry much about the specific implementation that users prefer?

Is there a good reason not to do this?

Yes, this should happen, also the category used in the website should be put in the metadata. Just cruftiness that keeps them separate. Patches plz kthx!

–Noah


#4

And metadata should have a “maintainer_repository” added.

http://tickets.opscode.com/browse/CHEF-286

On Nov 14, 2012, at 22:27, “Noah Kantrowitz” <noah@coderanger.netmailto:noah@coderanger.net> wrote:

On Nov 14, 2012, at 9:09 PM, Jesse Nelson wrote:

Would it make sense for us to consider adding the external url info to metadata ? This way berks/librarian/whisk/whatever tool can operate against the metadata, and cookbook makers don’t have to worry much about the specific implementation that users prefer?

Is there a good reason not to do this?

Yes, this should happen, also the category used in the website should be put in the metadata. Just cruftiness that keeps them separate. Patches plz kthx!

–Noah


#5

I’ve always thought that include_recipe is an anti-pattern if you’re
including recipes outside of the cookbook you’re in. It introduces coupling
that’s too vague since anyone can download a cookbook of the same name and
upload it to the chef server. It may or may not have been the specific
dependency cookbook the author intended it to be. Case in point, there are
a couple cookbooks floating around out there in the wild with the exact
same name, ‘nodejs’. There are multiple statsd cookbooks that appear to
include_recipe ‘nodejs’ except they actually mean to refer to different
implementations. (As a disclaimer it’s late and that’s just an example I
remember running into previously when working with third party cookbooks.
I’d have to go find the specific repos to prove that this example exists in
the wild.)

All over the opscode cookbooks this pattern is used, with the implicit
understanding that these couplings are between the opscode cookbooks of
these names. It seems to be alright if I stay within the confines of
github.com/opscode-cookbooks, but once you start to pull in cookbooks on
the community site that weren’t created / condoned by opscode or from some
stranger’s git repo then you may not have any context as to which specific
cookbook implementation they meant to call via the include_recipe function.
So yes, I’m all for stronger specificity in dependency management between
cookbooks.

Maintainer_repo as a url within the metadata.rb is a good idea. But I think
the depends statement should take a git/url parameter so the dependency
chain is more explicit and less reliant on context and naming. The only
downside of this is what do I do if I intend to intentionally alter the
dependency chain by pointing to my fork of an opscode cookbook because I’ve
fixed some bug that’s relevant to my work and hasn’t been merged in yet. I
wouldn’t say I have a good solution for that.

All this to say, I’ve kind of written off include_recipe as taboo on our
team. I tend to subscribe more heavily to the philosophy that every
cookbook should have corresponding role or roles that explicitly
encapsulates it’s dependencies. That gives you two things, one is that when
people need to pull together new nodes, they only need to compose their
runlists out of roles. Since those roles encapsulate all of their
dependencies by convention then the operator need not be familiar with all
the peculiarities of the naming of the underlying cookbooks and their
implicit couplings. The second is that at a glance you can see exactly
what’s going to be installed on a node by inspecting the roles.

I adopted this pattern of using roles and eschewing metadata.rb’s depends &
include_recipe because of the growing pains I had trying to figure all of
this out during my first year with Chef. I learned through a fair amount of
trial and error to try to stick within the confines of opscode-cookbooks,
and if I didn’t then i should rgrep for include_recipe in any third party
cookbook to see if I’m likely going to end up with some dependency headache
down the line. I guess the only reason I wrote out this little epic was
just to highlight some growing pains I had with chef pertaining to this
topic and to mention the coping mechanisms I’ve had to adopt that appear to
fly in the face of conventional wisdom within the community.

Best Regards,

Kevin Nuckolls

On Wed, Nov 14, 2012 at 11:48 PM, Joshua Timberman joshua@opscode.comwrote:

And metadata should have a “maintainer_repository” added.

http://tickets.opscode.com/browse/CHEF-286

On Nov 14, 2012, at 22:27, “Noah Kantrowitz” noah@coderanger.net wrote:

On Nov 14, 2012, at 9:09 PM, Jesse Nelson wrote:

Would it make sense for us to consider adding the external url info to
metadata ? This way berks/librarian/whisk/whatever tool can operate against
the metadata, and cookbook makers don’t have to worry much about the
specific implementation that users prefer?

Is there a good reason not to do this?

Yes, this should happen, also the category used in the website should be
put in the metadata. Just cruftiness that keeps them separate. Patches plz
kthx!

–Noah


#6

On Nov 14, 2012, at 11:42 PM, Kevin Nuckolls wrote:

I’ve always thought that include_recipe is an anti-pattern if you’re including recipes outside of the cookbook you’re in. It introduces coupling that’s too vague since anyone can download a cookbook of the same name and upload it to the chef server. It may or may not have been the specific dependency cookbook the author intended it to be. Case in point, there are a couple cookbooks floating around out there in the wild with the exact same name, ‘nodejs’. There are multiple statsd cookbooks that appear to include_recipe ‘nodejs’ except they actually mean to refer to different implementations. (As a disclaimer it’s late and that’s just an example I remember running into previously when working with third party cookbooks. I’d have to go find the specific repos to prove that this example exists in the wild.)

All over the opscode cookbooks this pattern is used, with the implicit understanding that these couplings are between the opscode cookbooks of these names. It seems to be alright if I stay within the confines of github.com/opscode-cookbooks, but once you start to pull in cookbooks on the community site that weren’t created / condoned by opscode or from some stranger’s git repo then you may not have any context as to which specific cookbook implementation they meant to call via the include_recipe function. So yes, I’m all for stronger specificity in dependency management between cookbooks.

Maintainer_repo as a url within the metadata.rb is a good idea. But I think the depends statement should take a git/url parameter so the dependency chain is more explicit and less reliant on context and naming. The only downside of this is what do I do if I intend to intentionally alter the dependency chain by pointing to my fork of an opscode cookbook because I’ve fixed some bug that’s relevant to my work and hasn’t been merged in yet. I wouldn’t say I have a good solution for that.

All this to say, I’ve kind of written off include_recipe as taboo on our team. I tend to subscribe more heavily to the philosophy that every cookbook should have corresponding role or roles that explicitly encapsulates it’s dependencies. That gives you two things, one is that when people need to pull together new nodes, they only need to compose their runlists out of roles. Since those roles encapsulate all of their dependencies by convention then the operator need not be familiar with all the peculiarities of the naming of the underlying cookbooks and their implicit couplings. The second is that at a glance you can see exactly what’s going to be installed on a node by inspecting the roles.

I adopted this pattern of using roles and eschewing metadata.rb’s depends & include_recipe because of the growing pains I had trying to figure all of this out during my first year with Chef. I learned through a fair amount of trial and error to try to stick within the confines of opscode-cookbooks, and if I didn’t then i should rgrep for include_recipe in any third party cookbook to see if I’m likely going to end up with some dependency headache down the line. I guess the only reason I wrote out this little epic was just to highlight some growing pains I had with chef pertaining to this topic and to mention the coping mechanisms I’ve had to adopt that appear to fly in the face of conventional wisdom within the community.

What you describe is a much deeper change to how chef works and is not really relevant to the question of fixing cookbook metadata so there aren’t magic fields only the community site knows about. Thank you for the ideas though.

–Noah


#7

Kevin,

I agree with your point here, and In general I too try to encapsulate deps
in roles, but the thing that brought this up for me was interfacing with a
cookbook that had metadata librarian and berkshelf files. all calling out
deps. If I want to change that I should have single source of truth (with
the ability for any of those to override IMO) for where these sources are
from. I only started using depends when I started publishing cookbooks, and
really when I started to leverage berkshelf for everyday management.

maintainer_url is great for pointing to where the cookbook came from, but
I want to know where the cookbook author thinks the deps should resolve to.
When I am making a cook I want to be able to provide it to people so they
can use any tooling they like instead of just my opinions about how you
should get this cooks deps. If we had deps in meta call out sources then
tools like librarian and berkshelf could “just work” without a needed
Berksfile unless you wanted to override for whatever reason.

I guess I see the prevalence of cookbook management tools as a symptom to a
problem everyone has, and one small step towards simplifying would be
adding source metadata to depends.

On Thu, Nov 15, 2012 at 4:42 PM, Kevin Nuckolls kevin.nuckolls@gmail.comwrote:

I’ve always thought that include_recipe is an anti-pattern if you’re
including recipes outside of the cookbook you’re in. It introduces coupling
that’s too vague since anyone can download a cookbook of the same name and
upload it to the chef server. It may or may not have been the specific
dependency cookbook the author intended it to be. Case in point, there are
a couple cookbooks floating around out there in the wild with the exact
same name, ‘nodejs’. There are multiple statsd cookbooks that appear to
include_recipe ‘nodejs’ except they actually mean to refer to different
implementations. (As a disclaimer it’s late and that’s just an example I
remember running into previously when working with third party cookbooks.
I’d have to go find the specific repos to prove that this example exists in
the wild.)

All over the opscode cookbooks this pattern is used, with the implicit
understanding that these couplings are between the opscode cookbooks of
these names. It seems to be alright if I stay within the confines of
github.com/opscode-cookbooks, but once you start to pull in cookbooks on
the community site that weren’t created / condoned by opscode or from some
stranger’s git repo then you may not have any context as to which specific
cookbook implementation they meant to call via the include_recipe function.
So yes, I’m all for stronger specificity in dependency management between
cookbooks.

Maintainer_repo as a url within the metadata.rb is a good idea. But I
think the depends statement should take a git/url parameter so the
dependency chain is more explicit and less reliant on context and naming.
The only downside of this is what do I do if I intend to intentionally
alter the dependency chain by pointing to my fork of an opscode cookbook
because I’ve fixed some bug that’s relevant to my work and hasn’t been
merged in yet. I wouldn’t say I have a good solution for that.

All this to say, I’ve kind of written off include_recipe as taboo on our
team. I tend to subscribe more heavily to the philosophy that every
cookbook should have corresponding role or roles that explicitly
encapsulates it’s dependencies. That gives you two things, one is that when
people need to pull together new nodes, they only need to compose their
runlists out of roles. Since those roles encapsulate all of their
dependencies by convention then the operator need not be familiar with all
the peculiarities of the naming of the underlying cookbooks and their
implicit couplings. The second is that at a glance you can see exactly
what’s going to be installed on a node by inspecting the roles.

I adopted this pattern of using roles and eschewing metadata.rb’s depends
& include_recipe because of the growing pains I had trying to figure all of
this out during my first year with Chef. I learned through a fair amount of
trial and error to try to stick within the confines of opscode-cookbooks,
and if I didn’t then i should rgrep for include_recipe in any third party
cookbook to see if I’m likely going to end up with some dependency headache
down the line. I guess the only reason I wrote out this little epic was
just to highlight some growing pains I had with chef pertaining to this
topic and to mention the coping mechanisms I’ve had to adopt that appear to
fly in the face of conventional wisdom within the community.

Best Regards,

Kevin Nuckolls

On Wed, Nov 14, 2012 at 11:48 PM, Joshua Timberman joshua@opscode.comwrote:

And metadata should have a “maintainer_repository” added.

http://tickets.opscode.com/browse/CHEF-286

On Nov 14, 2012, at 22:27, “Noah Kantrowitz” noah@coderanger.net wrote:

On Nov 14, 2012, at 9:09 PM, Jesse Nelson wrote:

Would it make sense for us to consider adding the external url info to
metadata ? This way berks/librarian/whisk/whatever tool can operate against
the metadata, and cookbook makers don’t have to worry much about the
specific implementation that users prefer?

Is there a good reason not to do this?

Yes, this should happen, also the category used in the website should be
put in the metadata. Just cruftiness that keeps them separate. Patches plz
kthx!

–Noah


#8

I think maybe adding the maintainer_repo to the metadata, and making an
additional optional field for the depends git url would be an adequate
solution. The cookbook maintainer can set explicit dependencies to specific
cookbooks on github. Librarian, Berkshelf, etc can be extended to take that
optional parameter into account.

It could be as simple as that. If you as the chef operator want to override
some part of the dependency chain, just put a reference to the cookbook you
want in your Cheffile / Berksfile.

On Thu, Nov 15, 2012 at 2:36 AM, Jesse Nelson spheromak@gmail.com wrote:

Kevin,

I agree with your point here, and In general I too try to encapsulate
deps in roles, but the thing that brought this up for me was interfacing
with a cookbook that had metadata librarian and berkshelf files. all
calling out deps. If I want to change that I should have single source of
truth (with the ability for any of those to override IMO) for where these
sources are from. I only started using depends when I started publishing
cookbooks, and really when I started to leverage berkshelf for everyday
management.

maintainer_url is great for pointing to where the cookbook came from, but
I want to know where the cookbook author thinks the deps should resolve to.
When I am making a cook I want to be able to provide it to people so they
can use any tooling they like instead of just my opinions about how you
should get this cooks deps. If we had deps in meta call out sources then
tools like librarian and berkshelf could “just work” without a needed
Berksfile unless you wanted to override for whatever reason.

I guess I see the prevalence of cookbook management tools as a symptom to
a problem everyone has, and one small step towards simplifying would be
adding source metadata to depends.

On Thu, Nov 15, 2012 at 4:42 PM, Kevin Nuckolls kevin.nuckolls@gmail.comwrote:

I’ve always thought that include_recipe is an anti-pattern if you’re
including recipes outside of the cookbook you’re in. It introduces coupling
that’s too vague since anyone can download a cookbook of the same name and
upload it to the chef server. It may or may not have been the specific
dependency cookbook the author intended it to be. Case in point, there are
a couple cookbooks floating around out there in the wild with the exact
same name, ‘nodejs’. There are multiple statsd cookbooks that appear to
include_recipe ‘nodejs’ except they actually mean to refer to different
implementations. (As a disclaimer it’s late and that’s just an example I
remember running into previously when working with third party cookbooks.
I’d have to go find the specific repos to prove that this example exists in
the wild.)

All over the opscode cookbooks this pattern is used, with the implicit
understanding that these couplings are between the opscode cookbooks of
these names. It seems to be alright if I stay within the confines of
github.com/opscode-cookbooks, but once you start to pull in cookbooks on
the community site that weren’t created / condoned by opscode or from some
stranger’s git repo then you may not have any context as to which specific
cookbook implementation they meant to call via the include_recipe function.
So yes, I’m all for stronger specificity in dependency management between
cookbooks.

Maintainer_repo as a url within the metadata.rb is a good idea. But I
think the depends statement should take a git/url parameter so the
dependency chain is more explicit and less reliant on context and naming.
The only downside of this is what do I do if I intend to intentionally
alter the dependency chain by pointing to my fork of an opscode cookbook
because I’ve fixed some bug that’s relevant to my work and hasn’t been
merged in yet. I wouldn’t say I have a good solution for that.

All this to say, I’ve kind of written off include_recipe as taboo on our
team. I tend to subscribe more heavily to the philosophy that every
cookbook should have corresponding role or roles that explicitly
encapsulates it’s dependencies. That gives you two things, one is that when
people need to pull together new nodes, they only need to compose their
runlists out of roles. Since those roles encapsulate all of their
dependencies by convention then the operator need not be familiar with all
the peculiarities of the naming of the underlying cookbooks and their
implicit couplings. The second is that at a glance you can see exactly
what’s going to be installed on a node by inspecting the roles.

I adopted this pattern of using roles and eschewing metadata.rb’s depends
& include_recipe because of the growing pains I had trying to figure all of
this out during my first year with Chef. I learned through a fair amount of
trial and error to try to stick within the confines of opscode-cookbooks,
and if I didn’t then i should rgrep for include_recipe in any third party
cookbook to see if I’m likely going to end up with some dependency headache
down the line. I guess the only reason I wrote out this little epic was
just to highlight some growing pains I had with chef pertaining to this
topic and to mention the coping mechanisms I’ve had to adopt that appear to
fly in the face of conventional wisdom within the community.

Best Regards,

Kevin Nuckolls

On Wed, Nov 14, 2012 at 11:48 PM, Joshua Timberman joshua@opscode.comwrote:

And metadata should have a “maintainer_repository” added.

http://tickets.opscode.com/browse/CHEF-286

On Nov 14, 2012, at 22:27, “Noah Kantrowitz” noah@coderanger.net
wrote:

On Nov 14, 2012, at 9:09 PM, Jesse Nelson wrote:

Would it make sense for us to consider adding the external url info to
metadata ? This way berks/librarian/whisk/whatever tool can operate against
the metadata, and cookbook makers don’t have to worry much about the
specific implementation that users prefer?

Is there a good reason not to do this?

Yes, this should happen, also the category used in the website should be
put in the metadata. Just cruftiness that keeps them separate. Patches plz
kthx!

–Noah


#9

On Thu, Nov 15, 2012 at 6:42 PM, Kevin Nuckolls
kevin.nuckolls@gmail.com wrote:

I’ve always thought that include_recipe is an anti-pattern if you’re
including recipes outside of the cookbook you’re in.

While I can see how you have got to the place you are currently at, it
is almost the exact opposite to where we are.

We started out using your approach but as roles are un-versioned or we
wanted more complex logic in resolving our attributes between
roles/environments/nodes we found ourselves engineered into a dead
end. Our roles now all include one recipe, the so called “role
recipe”.

This role cookbook depends on all the cookbooks it uses and the role
recipe includes them in a particular order. This allows us to have
multiple versions of the role deployed. i.e. We could add a recipe to
the role in version 2 of the role cookbook and roll it out to the
development environment while version 1 is still present in the
integration/uat/staging/production environments.

When we want complex resolution rules around attributes we can also
put it in the role recipe rather than trying to navigate the attribute
precedence rules.

All in all. The only value that the roles structure in chef provides
us is the ability to identify top level cookbook/recipes that can be
safely applied to a node.

Here’s an illustrative example…

— roles/foo.rb —
name "foo"
description "Foo Server"
run_list(“recipe[mybiz-foo]”)

— cookbooks/mybiz-foo/metadata.rb —

depends "ntp"
depends "git"
depends “foo”

— cookbooks/mybiz-foo/recipes/default.rb —
include_recipe "ntp"
include_recipe "git"
include_recipe “foo”

Maintainer_repo as a url within the metadata.rb is a good idea. But I think
the depends statement should take a git/url parameter so the dependency
chain is more explicit and less reliant on context and naming.

That is actually fairly interesting to us. But rather than a git URL I
would prefer it to be a namespace that correlates to the namespace in
community site when/if that ever happens.


Cheers,

Peter Donald


#10

+1 almost identical to how we do it.

But we also tend to split up things within that role/application cookbook. So

— mybiz-foo/recipes/default.rb —
include_recipe "mybiz-foo::package"
include_recipe "mybiz-foo::ulimit"
include_recipe "mybiz-foo::service"
include_recipe "mybiz-foo::monit"
include_recipe "mybiz-foo::logrotate"
include_recipe "mybiz-foo::backup"
include_recipe "mybiz-foo::ganglia"
include_recipe “mybiz-foo::nrpe”

Each of those then includes the necessary recipes and/or resources from external cookbooks.

On 2012-11-15, at 12:38, Peter Donald wrote:

On Thu, Nov 15, 2012 at 6:42 PM, Kevin Nuckolls
kevin.nuckolls@gmail.com wrote:

I’ve always thought that include_recipe is an anti-pattern if you’re
including recipes outside of the cookbook you’re in.

While I can see how you have got to the place you are currently at, it
is almost the exact opposite to where we are.

We started out using your approach but as roles are un-versioned or we
wanted more complex logic in resolving our attributes between
roles/environments/nodes we found ourselves engineered into a dead
end. Our roles now all include one recipe, the so called “role
recipe”.

This role cookbook depends on all the cookbooks it uses and the role
recipe includes them in a particular order. This allows us to have
multiple versions of the role deployed. i.e. We could add a recipe to
the role in version 2 of the role cookbook and roll it out to the
development environment while version 1 is still present in the
integration/uat/staging/production environments.

When we want complex resolution rules around attributes we can also
put it in the role recipe rather than trying to navigate the attribute
precedence rules.

All in all. The only value that the roles structure in chef provides
us is the ability to identify top level cookbook/recipes that can be
safely applied to a node.

Here’s an illustrative example…

— roles/foo.rb —
name "foo"
description "Foo Server"
run_list(“recipe[mybiz-foo]”)

— cookbooks/mybiz-foo/metadata.rb —

depends "ntp"
depends "git"
depends “foo”

— cookbooks/mybiz-foo/recipes/default.rb —
include_recipe "ntp"
include_recipe "git"
include_recipe “foo”

Maintainer_repo as a url within the metadata.rb is a good idea. But I think
the depends statement should take a git/url parameter so the dependency
chain is more explicit and less reliant on context and naming.

That is actually fairly interesting to us. But rather than a git URL I
would prefer it to be a namespace that correlates to the namespace in
community site when/if that ever happens.


Cheers,

Peter Donald


#11

On Fri, Nov 16, 2012 at 7:38 AM, Peter Donald peter@realityforge.org wrote:

On Thu, Nov 15, 2012 at 6:42 PM, Kevin Nuckolls
kevin.nuckolls@gmail.com wrote:

I’ve always thought that include_recipe is an anti-pattern if you’re
including recipes outside of the cookbook you’re in.

While I can see how you have got to the place you are currently at, it
is almost the exact opposite to where we are.

We started out using your approach but as roles are un-versioned or we
wanted more complex logic in resolving our attributes between
roles/environments/nodes we found ourselves engineered into a dead
end. Our roles now all include one recipe, the so called “role
recipe”.

And I decided to clarify the idea with a blog post.

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

HTH,

Peter Donald


#12

Am 15.11.2012 21:38 schrieb “Peter Donald” peter@realityforge.org:

On Thu, Nov 15, 2012 at 6:42 PM, Kevin Nuckolls
kevin.nuckolls@gmail.com wrote:

I’ve always thought that include_recipe is an anti-pattern if you’re
including recipes outside of the cookbook you’re in.

While I can see how you have got to the place you are currently at, it
is almost the exact opposite to where we are.

We started out using your approach but as roles are un-versioned or we
wanted more complex logic in resolving our attributes between
roles/environments/nodes we found ourselves engineered into a dead
end. Our roles now all include one recipe, the so called “role
recipe”.

This role cookbook depends on all the cookbooks it uses and the role
recipe includes them in a particular order. This allows us to have
multiple versions of the role deployed. i.e. We could add a recipe to
the role in version 2 of the role cookbook and roll it out to the
development environment while version 1 is still present in the
integration/uat/staging/production environments.

When we want complex resolution rules around attributes we can also
put it in the role recipe rather than trying to navigate the attribute
precedence rules.

All in all. The only value that the roles structure in chef provides
us is the ability to identify top level cookbook/recipes that can be
safely applied to a node.

Here’s an illustrative example…

— roles/foo.rb —
name "foo"
description "Foo Server"
run_list(“recipe[mybiz-foo]”)

— cookbooks/mybiz-foo/metadata.rb —

depends "ntp"
depends "git"
depends “foo”

— cookbooks/mybiz-foo/recipes/default.rb —
include_recipe "ntp"
include_recipe "git"
include_recipe “foo”

Maintainer_repo as a url within the metadata.rb is a good idea. But I
think

the depends statement should take a git/url parameter so the dependency
chain is more explicit and less reliant on context and naming.

That is actually fairly interesting to us. But rather than a git URL I
would prefer it to be a namespace that correlates to the namespace in
community site when/if that ever happens.

And +1 for namespaces


Cheers,

Peter Donald


#13

Yeah I hadn’t even considered namespaces. That seems like the cleanest
solution.

On Sat, Nov 17, 2012 at 9:16 AM, Torben Knerr ukio@gmx.de wrote:

Am 15.11.2012 21:38 schrieb “Peter Donald” peter@realityforge.org:

On Thu, Nov 15, 2012 at 6:42 PM, Kevin Nuckolls
kevin.nuckolls@gmail.com wrote:

I’ve always thought that include_recipe is an anti-pattern if you’re
including recipes outside of the cookbook you’re in.

While I can see how you have got to the place you are currently at, it
is almost the exact opposite to where we are.

We started out using your approach but as roles are un-versioned or we
wanted more complex logic in resolving our attributes between
roles/environments/nodes we found ourselves engineered into a dead
end. Our roles now all include one recipe, the so called “role
recipe”.

This role cookbook depends on all the cookbooks it uses and the role
recipe includes them in a particular order. This allows us to have
multiple versions of the role deployed. i.e. We could add a recipe to
the role in version 2 of the role cookbook and roll it out to the
development environment while version 1 is still present in the
integration/uat/staging/production environments.

When we want complex resolution rules around attributes we can also
put it in the role recipe rather than trying to navigate the attribute
precedence rules.

All in all. The only value that the roles structure in chef provides
us is the ability to identify top level cookbook/recipes that can be
safely applied to a node.

Here’s an illustrative example…

— roles/foo.rb —
name "foo"
description "Foo Server"
run_list(“recipe[mybiz-foo]”)

— cookbooks/mybiz-foo/metadata.rb —

depends "ntp"
depends "git"
depends “foo”

— cookbooks/mybiz-foo/recipes/default.rb —
include_recipe "ntp"
include_recipe "git"
include_recipe “foo”

Maintainer_repo as a url within the metadata.rb is a good idea. But I
think

the depends statement should take a git/url parameter so the dependency
chain is more explicit and less reliant on context and naming.

That is actually fairly interesting to us. But rather than a git URL I
would prefer it to be a namespace that correlates to the namespace in
community site when/if that ever happens.

And +1 for namespaces


Cheers,

Peter Donald