[chef] Re: Augeas support

[Mathieu Martin < >]

On the other hand, some of the differences in the way things are done in the RedHat family and the Debian family are pretty big. Writing a cross-platform cookbook that does things the way each platform does it wouldn't make sense, IMHO. It would be a very big effort (scamble to update every time one platform has a release, configure tools in fundamentally different ways, etc). And RedHat/Debian are only two platforms. There's also the BSDs, including MacOS, and well, Windows :-)

So I think for OpsCode and the Chef community at large, it makes sense to pick one way of doing it and use it for all platforms.

But I completely agree that it does't work well for RedHat-centric shops. Especially those who want to have support from RedHat. It sounds like an opportunity for someone to provide high quality RedHat-centric recipes! I wouldn't put the onus on OpsCode, though. They've done so much for us already.

Mat

On Sunday, February 17, 2013, Sam Darwin wrote:

Kevin wrote:

>>>For me, the Apache cookbook is actually fundamentally broken because it
deviates so much.

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.

These strategies are different enough that they might require two totally
different sets of cookbooks or else have an attribute switch inside a cookbook
like "minimal management" versus "total management".

And yes, it does seem to be related to the size of the environment.    A small
shop with 10 - 50 servers, and a small team, is different from a 1000 server
environment, in terms of which of these two methods you prefer.

"Everything should be made as simple as possible, but not simpler."

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.

Ok, a case can be made for both sides of this argument.

-- 
RockSolidRails: development & operations consulting for Ruby on Rails