Ok, I understand what you mean. But what have you done to optimize your
config/deployment? I could go extreme an say, I’ll write 3 mighty roles
1 for DEV, 1 for Q&A and 1 for production, but then I’ll have such
mighty/complex things … scary.
On 10/30/2010 12:15 AM, AJ Christensen wrote:
On 29 October 2010 14:29, Miquel Torres <email@example.com
I would like to subscribe to what Andrew said.
When the configuration of servers and applications grows organically
at a company, it often ends-up with myriads of gratuitous software
combinations and versions (just like evolution and life :-).
40-50 roles sounds like too many roles to me.
Depends on the infrastructure really! You can’t immediately go to the
smallest, simplest set of roles, no? Takes time.
For a long way, smashing roles together via run_list was the only way
to get correct attribute stacking behavior (i.e. totally neglecting
Cookbook attributes). Since this has been fixed, I’ve been shifting
mostly back to default attributes in new cookbooks. We’ve probably
just got legacy stuff hanging around =)
I’ve ended up having 12-15 “lump” roles that massage together a
smaller subset of bits (via run_list) who individually (generally)
have default attributes that aren’t exposed in the Cookbook attributes.
Just like code needs refactoring and cleanup from time to time, so
does configuration management.
2010/10/29 Andrew Shafer <firstname.lastname@example.org
> A word of advice, implementing configuration management is a
> time to revisit all the legacy decisions that created complexity
> environment. Don't waste the opportunity just redescribing what
> revisit the why it exists and move to simplify and standardize.
> On Fri, Oct 29, 2010 at 3:09 PM, Christian Requena
>> I'm evaluating the introduction of Chef in an environment with
>> different types of server, delivering about 70 different
>> which are running partly different configurations. In other
words .. a
>> big mess ... or should I say, a big challenge? ;)
>> Any way, we're trying to figure out how to define roles for our
>> colourful environment. We came up with this:
>> |-- dishes/
>> |-- flavours/
>> |-- ingredients/
>> |-- locations/
>> `-- misc/
>> I'm trying to categorize the degrees of freedom we have
>> application/ operational needs.
>> * An "ingredient" is equivalent to a operational component (i.e.
>> apache2, nginx, squid...) or an application. Anything we
>> * A "flavour" is a special characteristic that can be
>> activated/deactivated on a set of servers.
>> * A "dish" are things you can define as a set of "ingredients" and
>> "flavours". This are i.e. the different types of servers we manage.
>> * A "location" will be a group of dishes, i.e. if you create a
>> group of server to deliver a functionality for testing
/developing or a
>> set of web-servers.
>> * "misc" for those thing I forgot about.
>> We just figured out, that chef doesn't support this approach.
>> So my question will be: What will you do to manage this kind of
>> scenario? I don't want to work on a directory with way over 100
>> configuration files, do you see another way to manage this?
>> Thanks a lot for you help