[chef] RE: Re: Re: Re: Re: Re: Role Versioning?

[Kevin Keane Subscription < >]

Title: RE: [chef] Re: Re: Re: Re: Re: Role Versioning?

For this exact reason, in my own top-level cookbook, I am not using include_recipe, but rather node.run_list.add (actually, I'm using a mix of the two).

The effect is *almost* the same, but because the recipes are added to the runlist, they are searchable.

One difference is that these recipes will not take effect until the *next* chef run.

The second difference is that with include_recipe, you have more control over order-of-execution. In my mind, that's actually a benefit; include_recipe tempts you to think procedurally instead of declaratively.

A third difference is that I don't need to declare all the cookbooks as dependency in my top-level cookbook. With include_recipe, I may have dependencies on many cookbooks that aren't even relevant to a particular server. It makes it easier to have a single top-level cookbook for all my servers and use a big case statement to distinguish the servers.

Of course you can still declare a dependency in the metadata if you need it to lock down a version number. You just don't *have* to do it for all your recipes.

-----Original message-----
From: Torben Knerr < >
Sent: Thursday 14th February 2013 14:21
To:
Subject: [chef] Re: Re: Re: Re: Re: Role Versioning?

The only but very very big limitation of the "application cookbook" / "role cookbook" / "top level cookbook" pattern is that due to the `include_recipe`s the included recipes don't show up in the run_list anymore and thus you can't search for them (which breaks many of the community cookbooks, e.g. apt).