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

[Matthew Kent < >]

On Fri, 2010-07-30 at 21:41 -0500, Leinartas, Michael wrote:

<snip>

> 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

Sorry for chiming in rather late but your workflow is pretty much what
I've been using here successfully.

Quick rundown:

* Generic cookbooks filled with attributes that closely match the
package defaults or are otherwise unset. 
* Templates that closely match the upstream versions.
* Roles for everything, even single servers, so everything is tracked in
source control. We use development/staging/production roles for many
groups of servers. The roles are layered (baseline, roaming-profiles,
web-production) and we have a top level role for each system that
includes them all so the run_list for each system is represented in the
ui by only one role.
* Rake helper task to speed up the sync of cookbooks/roles to the server
after every change (http://gist.github.com/501440)
* Development chef server/client pair for each developer for testing.
Changes are passed to me in branches for review/merge/deploy.
* Client runs are triggered manually - though this may change shortly if
I can get the reporting hooks going.

If I can ever find the time I'd love to put together a functioning demo
repo and doc for this workflow.

-- 
Matthew Kent \ SA \ bravenet.com