My opinion (and I don’t know if it’s a very popular one), is that
include_recipe is an anti-pattern when used between cookbooks. It deeply
couples the implementation details of two separate cookbooks. When using
open sourced cookbooks that use include_recipe, you often are required to
use the specific cookbooks that one was written against.
My solution has been that cookbooks and recipes are to be written in
isolation and be heavily managed by attributes. A piece of software and
all of it’s dependencies should be wrapped up in the run_lists in one
nice little role. That way anyone composing a new node merely has to choose
from the available roles and know full well that their dependencies are
encapsulated in that role. This pattern has been quite successful. Our
junior developers are able to pull in the roles they need, without being
concerned with the implementation details of the underlying cookbooks.
We have a role for every piece of infrastructure, even if it only has one
recipe in it’s run_list right now. The idea is that the cookbook may change
over time and introduce dependencies. If we composed the nodes with a
"role" per infrastructure component from the beginning, we merely have to
update the role and promote those cookbook changes to the production
If a cookbook supplies providers, I make a recipe called “providers” and
call it via something like “recipe[rabbitmq::providers]”. That makes it
explicit that I’m to be using the providers from a given cookbook for later
recipes in this role.
Keeps things clean, decoupled, and provides a higher level layer on top of
the cookbooks to compose infrastructure from.
Hope that helps!
On Fri, Aug 10, 2012 at 3:05 AM, Millisi firstname.lastname@example.org wrote:
I just want include that the chef env will also help to manage n
develop/enhance the production cookbook without messing with the running
version of cookbook.
In the env file, u can specify the version of the cookbook.
Via Millisami’z iPhone
On Aug 9, 2012, at 8:05 PM, Dan Crosta email@example.com wrote:
include_recipe actually includes (and runs) a recipe. When used in the
shorthand form, like
It runs the default recipe from that cookbook, just as including
"recipe[other_cookbook]" in a role run_list would do. To have Chef manage
dependencies for you, you should use the “depends” attribute in your
cookbook metadata. For example, in metadata.rb, you would add:
(There is a similar form if you are using metadata.json directly.) Now
when Chef runs and realizes that it needs to include your current cookbook,
it will also include other_cookbook.
To use an LWRP from another cookbook, I don’t believe you need to
include_recipe at all (someone please correct me if I’m wrong), you just
need to have that cookbook available on the system (which is what depends
does). Note however that some LWRPs also expect a corresponding recipe to
be run, either before or after – so read the instructions from that
On Aug 9, 2012, at 10:00 AM, Alfredo Palhares wrote:
Hello Chef Cookers,
I am looking for a way to manage cookbook dependencies, as our
grows and thus the complexity too, dependencies are becoming hard to
We use include_recipe in cases where we only use a lightweight resource
by that particular cookbook. Since include_recipe only loads the direct
and not the includes that cookbook might contains.
Why it does not do this?
Is it a design option?
Or a limitation that is going to be completed in the future?
I would like to hear your opinion on this.