[chef] Re: Re: Re: RE: Augeas support

[Joshua Timberman < >]

Ohai,

A couple things...

On Feb 17, 2013, at 2:43 AM, Sam Darwin 
<
 >
 wrote:

> This is the view which I have also.   I have also re-written the apache
> cookbook.     It appears there are two valid strategies for managing 
> servers.  
> The current opcode cookbooks have chosen one of the strategies, and left the
> other one as an exercise for the reader.    For me, I would like to see 
> recipes
> which keep things as close as possible to the native vendor packages, and 
> which
> change as little as possible.   There are dependencies: let's say that 
> nagios
> depends on apache or something.  Now nagios can't run properly on redhat
> either, without being converted to debian nagios.   It is a cascading 
> series of
> dependencies.   I can't just run plain vanilla apache and plain ordinary
> nagios on redhat??    Not with the current site cookbook.      A customized
> cookbook is needed.    

By all means, don't use the community cookbook if it doesn't fit your 
preference, use case, supported platforms or standards.

However, please do understand that cookbook authors that build cross platform 
cookbooks have to make a choice.

1. Adhere to the policies and practices for specific platforms they support.
2. Pick a single policy/practice pattern and apply that to all the platforms.

The Opscode cookbooks generally follow #2. We try to abstract specific naming 
conventions and filesystem locations with attributes.

> Shouldn't a recipe on redhat, take advantage of the redhat packages as they 
> are
> and make the smallest, fewest, and simplest changes to get things up and
> running?      What is happening currently is that in many cookbook cases the
> file locations are being moved around to different places, startup scripts 
> are
> modified, configs are modified, etc etc so that things don't look like a
> default redhat package anymore.      


It shouldn't necessarily do the "Red Hat" things if it makes it harder for 
community-shared cookbooks to be used on multiple platforms. Sometimes, it 
can make sense to have a Red Hat specific recipe for something. But when a 
cookbook provides reusable primitives like the apache cookbook's definitions.

Using Apache HTTPD as an example is a great exploration into the insanity of 
managing something that is at it's core relatively simple to install and run. 
At the end of the day, you have:

1. A package of files that get extracted on disk.
2. A configuration file.
3. A daemonized service that runs.

Of course, if you look across the general ecosystem, you see different 
package approaches. There are definitely different configuration approaches. 
And yes, there are even different service approaches. If you run a 
multi-platform environment, you have to know all of these in order to 
maintain Apache HTTPD. Most likely though, you'll have adapted a single 
platform's approach, usually whichever one is the most common in your 
environment.

That's what we did when we originally wrote the Opscode apache2 cookbook, as 
we found the sites-{available,enabled} pattern to be really simple to use 
under configuration management.

-- 
Joshua Timberman
Technical Community Manager, Opscode, Inc
IRC, Skype, Twitter, Github: jtimberman