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

[Alex Soto < >]

Thanks Matthew, 

I really like your layering of the roles.  I'm wondering if you follow any 
naming convention for your roles?

Alex

On Aug 4, 2010, at 1:17 PM, Matthew Kent wrote:

> 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
>