>
> A word of advice, implementing configuration management is a
really good
> time to revisit all the legacy decisions that created complexity
in your
> environment. Don't waste the opportunity just redescribing what
exists,
> revisit the why it exists and move to simplify and standardize.
>
>
> On Fri, Oct 29, 2010 at 3:09 PM, Christian Requena <
">
>
> wrote:
>>
>> Hola!
>>
>> I'm evaluating the introduction of Chef in an environment with
about 40
>> different types of server, delivering about 70 different
applications
>> 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:
>>
>> roles/
>> |-- dishes/
>> |-- flavours/
>> |-- ingredients/
>> |-- locations/
>> `-- misc/
>>
>> I'm trying to categorize the degrees of freedom we have
concerning our
>> application/ operational needs.
>>
>> * An "ingredient" is equivalent to a operational component
(i.e.
>> apache2, nginx, squid...) or an application. Anything we
configure or
>> deploy.
>> * 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
small
>> 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
>
>