Idioms: role run_list+attributes vs role-specific recipe?


#1

I’m new to Chef, and I realized that as I include cookbooks, sometimes
I’m adding the recipe to the role’s run_list and using
default_attributes to control it, and sometimes I’m adding it to a
site-cookbook recipe I’ve created specifically for the role. For example…

Directly on the role:

roles/base.rb

run_list(
‘recipe[sudo]’,
)
default_attributes(
authorization: {
sudo: {
users: [‘jlevitt’],
passwordless: true
}
},

In a role-specific recipe:

roles/base.rb

run_list(
‘recipe[plm-roles::base]’
)

cookbooks/plm-roles/recipes/base.rb

include_recipe ‘sudo’

sudo “jlevitt” do
user "jlevitt"
nopasswd true
end

Does anyone have a good philosophy or idiomatic advice as to what goes
where? So far, I’m thinking:

  • There are some cookbooks that are controlled purely through node/role
    attributes. I’m not sure it’s kosher to set those from my own recipe.
  • If it’s not kosher, I’ve now arbitrarily split up cookbooks based on
    their API. That feels icky.
  • OTOH, for cookbooks with LWRPs, I do like the idea of keeping the
    attributes near the provider call; in the sudo example, I was actually
    using the run_list+attribute syntax, and when I moved the recipe to a
    different role, I forgot to move the attributes with it.
  • On the gripping hand, the second syntax means that I have not only a
    run_list per role, but a recipe per role. That doesn’t seem DRY.

Thoughts?

Jay


#2

Hi,

On Wed, Aug 1, 2012 at 3:23 AM, Jay Levitt jay.levitt@gmail.com wrote:

Does anyone have a good philosophy or idiomatic advice as to what goes
where? So far, I’m thinking:

  • There are some cookbooks that are controlled purely through node/role
    attributes. I’m not sure it’s kosher to set those from my own recipe.
  • If it’s not kosher, I’ve now arbitrarily split up cookbooks based on
    their API. That feels icky.
  • OTOH, for cookbooks with LWRPs, I do like the idea of keeping the
    attributes near the provider call; in the sudo example, I was actually
    using the run_list+attribute syntax, and when I moved the recipe to a
    different role, I forgot to move the attributes with it.
  • On the gripping hand, the second syntax means that I have not only a
    run_list per role, but a recipe per role. That doesn’t seem DRY.

We started with putting most configuration on the role. However this got
harder over time as attribute data differed between environments or we
wanted to started to synthesise attribute configuration data. It got even
harder when we moved to an “attribute_driven” [1] approach. So now we
mostly have a “policy” cookbook in which we do all the configuration and
then include the appropriate worker cookbooks. Not all of our roles have a
1-to-1 relationship with a cookbook/recipe but most of the
complex/bespoke/customized roles do. As always YMMV

[1]
http://realityforge.org/code/2012/05/12/evolving-towards-cookbook-reusability-in-chef.html


Cheers,

Peter Donald