FreeBSD is inherently a little different on this. The whole concept of a ports tree encourages this way of working. I actually have a strict policy against installing from source, because it tends to break so much.
I think it's also a matter of scale. When you use Chef to manage thousands of identical servers, cookbook development cost is barely a blip in your budget, but a server losing 5% performance due to a poor configuration choice may mean you have to add a dozen additional machines.
I'm running a small business, with about 10 servers, each one is different. For me, the cookbook development is the major cost factor; my server cost is near zero. I'm using Chef basically to have a central repository of all configuration changes, and as a disaster-recovery tool. Instead of restoring a backup, Chef allows me to rebuild machines to a known state very quickly - just add data.
What that means is that I need to leverage the work RedHat and the CentOS volunteers (as well as Dag Wieers, Remi Collet etc.) have done as much as possible. If one of my servers is only running at 95% optimum, I generally don't care. My priority is minimum configuration, not highest performance, The last thing I want to do is reinvent every wheel that came out of Raleigh.
Besides that direct issue, straying from conventions has a huge additional cost. For me, the Apache cookbook is actually fundamentally broken because it deviates so much. I couldn't use it; I had to write my own.
There is the development effort for dependencies. Everything that depends on Apache also now need major cookbook development effort. You can't just find and install a drupal or wordpress or nagios or ... RPM - you have to create a big cookbook for it, too.
Then there is the support issue. The more you deviate from standard, the more you have to explain before you even can ask questions for help. If you are a RHEL customer, the first thing RedHat will tell you is "your system is in an unsupported configuration. Fix it before we'll even look at it".
The breakage goes further. Security? Do you have the resources to test that your Apache configuration is secure? Forget about things such as SELinux; Sorry, you are gonna have to manage all the file contexts on your own - an unrealistically large task. Logrotate? I don't know if the Apache cookbook uses its own log file locations, but now I have to test that, too. Logwatch?
Sure, after each point release, you have to verify and test anyway. Usually that's a fairly quick matter, because the builk of the work has already been done by RedHat. That's why I actually have, even in pre-Chef days, a strict policy against compiling anything from source.
I can certainly understand that it works for you. It just doesn't for me.
-----Original message-----
From: Andrea Campi < >
Sent: Sat 02-16-2013 08:38 am
Subject: [chef] Re: Re: RE: Augeas support
To: ;
Speaking as someone who uses FreeBSD and so is often affected by changes on other platforms:I don't mind, it's worth it.I want to manage the complete state of my machines with Chef, even if that means straying from the defaults set by the platform, or even from its conventions.Case in point: the Apache cookbook "forces" the Debian config layout on all other distros.And to me that's a feature, because I couldn't care less about what the FreeBSD or Debian projects think it's "the best way": what I care about is consistency within my organization.Of course that just shuffles the decision of what "the best way" is to the cookbook author (whether that may be the community or an employee).And so my take on the specific problem at hand is: maybe today you only modify one line; but maybe in 3 month you'll need to edit 5 more. Better bite the bullet and bring it all under control.And sure, after each release you will have to verify and test--but that's the case no matter what.If you weren't using Chef, would you just roll out a PHP upgrade to production without checking what changes your distro made to php.ini?I wouldn't, and Chef doesn't change the process much.On Sat, Feb 16, 2013 at 5:23 PM, Sam Darwin < "> > wrote:
To summarize what Kevin said:
- You have a long and interesting config file with hundreds of lines. This
file does change from version to version of the software.
- You want to change only one line such as timezone, and nothing more.
Given this scenario, which is better: to modify a single line of the config
file, or to manage the entire file.
If you manage the entire file, you are compelled to be aware of the differences
from version to version, and also from OS to OS. It's a rather big task. A
new version of the software will break your cookbook. A release on a
different operating system such as FreeBSD might break your cookbook.
On the other hand, if you tweak one single config parameter such as timezone..
well, that's all that you do.
Archive powered by MHonArc 2.6.16.