[chef] RE: Re: Augeas support


Chronological Thread 
  • From: Kevin Keane Subscription < >
  • To: < >
  • Subject: [chef] RE: Re: Augeas support
  • Date: Sat, 16 Feb 2013 00:31:53 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=sendgrid.info; h=subject :from:to:mime-version:content-type:in-reply-to:references :sender; q=dns; s=smtpapi; b=jln0xnPZxDU1NLtsQ1EGAXZ9RHlTI9HYMB2 ge+/v1DIoPmyeDCrrsNwDN1rzlxEU8kPtee/CbkT2NgNw9qGCv1RznlwxTk6LHag LZTBsv3DH/hFK8o0md61Ys9DUAedxsgFqboQqNfX91j7MF/m1Q9OGbk7fslMdJXI 9JXD7a3w=

Title: RE: [chef] Re: Augeas support
-----Original message-----
From: Noah Kantrowitz < >
Sent: Fri 02-15-2013 03:51 am
Subject: [chef] Re: Augeas support

On Feb 15, 2013, at 2:00 AM, < > wrote:

There are Ruby bindings, just make yourself a little LWRP and go nuts. As for why this is bad, expressing desired state as a series of deltas instead of absolute values leads to drift over time, the usual end result being that the set of recipes that worked over time on a bunch of hosts all of a sudden can't be used to provision from scratch or vice versa. For example, if you are depending on deltas from the standard Debian/RHEL config files and they make a change in a point release, you are then screwed (possibly).

I find that the drift problem is far worse with the manage-the-whole-config-file approach; it's one of my biggest peeves with Chef.

 

You have the same point-release problem you mentioned about deltas, just worse. After all, the only reason deltas would break is if the config file itself has changed - and that means that the one you manage in chef is already broken. You may just not know it. I've had a number of problems with that - and more insidiously, these are often things where things don't obviously break, but rather causes subtle problems.

 

There is a third approach, and I would like to see that implemented more solidly: editing config files. Right now, you can use Chef:Util:FileEdit. But that has no built-in idempotency, and generally is quite kludgey.

 

Yet, this is the approach that would continue to work almost no matter what.

 

In one extreme case, I needed to change *one* line in php.ini (the time zone) - but now I have to manage 1722 lines of configuration file. And I already know that I will have to revisit this when going from PHP 5.1 to 5.2, 5.3 or 5.4. If I didn't have to manage the whole php.ini, my recipe for it would work the same for all PHP versions.

 

In an ideal world, I'd be able to do something like this:

 

file_edit "*date.timezone =*" do

   value "date.timezone = America/Los Angeles"

end

 

The idea being that this resource should work somewhat like sed or awk work.

 

I've had similar problems with Apache and mysql recently.




Archive powered by MHonArc 2.6.16.

§