[chef] Re: Configuration location philosophies - what's yours?

[Jesse Nelson < >]

Your thinking pretty much aligns with where im at as well. When I
started with chef it was before data bags, and i wanted to be able to
back the "state" of the system with git. My decision then was to use
roles to drop static data and use attribute overrides to drive
cookbook behavior. this allowed the "data" to stay out of the cookbook
and the state of chef to be checked in. With the exception of the node
run-lists.  Cookbooks then become heavily data driven. This was the
way i wrapped my head around chef as a migration from puppet. where
there was almost exclusively static data, and a requirement was to
control the change going into puppet.

The stumbling block comes with the update process in my mind. How are
the workflows with chef going to play out. There are 2 people in my
organization who are writing cookbooks, and about 5 total who are
modifying attributes. When someone wants to change a single host you
need to create a new role or add attributes sets or case statements in
the cookbook, and this was not acceptable to me. Ideally people who
need to be twiddling attributes do not have to dive into cookbooks.
This way the logic in the cookbook can be heavily vetted and not such
a moving target one deployed to live systems.

 Where I am at now is that Data Bags are the static data (network,
users). and i still use role defaults for sane roles, and let
attribute data be twiddled via knife/api by the 5 end-users.  My only
issue with this approach so far is that there is no audit trail on
those updates, and I can't easily store state or state revision
external to chef. Having a hook on api calls to atribute updates could
help this.  There are probably other ways im ignorant too, but at this
point with couch being distributed across multiple nodes. I am not
stressing the recovery issue just the audit issue (who changed this
attribute that broke X on host Y, and what was it set to b4 the change
so working state can be restored asap.


my $0.02   apologies in advance for being longwinded.

On Fri, Jul 30, 2010 at 7:41 PM, Leinartas, Michael
<
 >
 wrote:
> As I set up an environment from scratch I've had to do some thinking about
> where I want to be putting the configuration within Chef.  Configuration can
> go in many places: The recipes themselves (e.g. a recipe that has a list of
> "user" resources in which you add to the recipe when you have new users),
> attribute files within recipes, in databags, in roles, on the nodes
> themselves (either set on the fly or by some json blobs you have lying
> around).  (that's about it, right?).
>
> It feels proper to make a decision as to where you intend to put most of
> your configuration.  I can imagine someone using databags almost
> exclusively, or relying exclusively on hardcoded data in recipes, etc.  What
> I'm wondering is what the preferences of the people on this list are?
>  What's 'normal' for chef?
>
> Here's what I've been trying (I'd love comments on this). Note that I just
> started with Chef in 0.9.6 so I dont know what it's like to not have
> databags, roles, attribute heirarchies, etc.
> My instinct is to define the behavior (cookbooks) generically and keep the
> actual configuration separate.  In that, I've been writing cookbooks driven
> entirely from attributes. I define default attributes in the cookbook with
> the intent of overriding most of them.  In my model, all of my configuration
> goes into Roles.  In the case of any one-off configuration, I plan to
> further override at the node level (and expect this to be rare).  I have
> multiple server types and multiple environments and so have several types of
> roles, some of which override one another (order matters - this is where it
> breaks down since there's no way to set explicit role dependency).
> So to illustrate, examples of 3 main types or levels of Roles:
> ServerRole - base role that every server gets
> WebappRole - a specific application category role - shouldnt conflict with
> another app role (like WebserverRole)
> StagingRole - an environment role. overrides only those attributes within
> the previous roles that differ between environments
>
> Any server in my environment that actually does anything will need one of
> each of these roles in this order (except dev which uses the defaults and
> doesnt need an env role).
> So far I've only used databags for things truely global to the environment
> like a list of hostnames and IPs to generate identical /etc/hosts files on
> each box.
>
> Comments? Is this way off from what other people do or does this fit with
> what youve seen before?
>
>