FYI
http://tickets.opscode.com/browse/CHEF-294
http://tickets.opscode.com/browse/CHEF-2570
Dennis
-----Original Message-----
From: Aaron Peterson [
">mailto:
]
Sent: Mon 8/8/2011 7:32 PM
To:
Subject: [[chef-dev]] Re: [[chef-dev]] Re: [[chef-dev]] Re: [[chef-dev]] new package resource action :reconfig
On Sun, Aug 7, 2011 at 07:10, Dennis Klein <
> wrote:
> I wonder what level of idempotency we need to achiev because when I look at
> the various file and template resources chef is shipping they basically dont
> care about the actual state of the live file they write. They just determine
> the state change depending on the chef-client cache (afaik, pls correct me,
> if I am wrong here). So, I feel to go along with the common "chef sense" of
> idempotency even option 1 would be sufficient ?!
>
There is a checksum compare of the live file as the test just before writing
it, a good guarantee of idempotency. See for example
https://github.com/opscode/chef/blob/master/chef/lib/chef/provider/file.rb#L65
You'll want an idempotent test as tight as is reasonable - you don't want to
be fooled in trivial cases, but truly confirming the existing state can be
expensive or difficult, as you've discussed. So we compromise: Chef trusts
what package management says about the state of a package, which will not
discover or fix a package if a file it delivered is somehow clobbered.
The problem here is reconfigure does a number of things and hides the
outcome of "did anything change?" which it may not actually know depending
on implementation. So you can have it :
* have the resource run every time - system inefficient, admin efficient,
"probably idempotent enough"
* (from your 1&2 above) be satisfied with a looser, less accurate sense of
idempotency - maybe okay, but situation dependent
* (from 3) essentially re-implement components of dpkg using concepts of
idempotency....but that sounds awfully familiar to and a lot harder than
this:
* manage the package components after their initial installation with chef
Of course that last one means giving up some benefits of being able to do
dpkg-managed reconfigures, but trades that for explicitly managing
and understanding the state of the contents of a given package in the same
way as rest of the configuration management you're doing with Chef.
So for the purposes of having reconfig in there at all, I'd keep it pretty
simple by having the provider not have a built-in concept of idempotency,
like execute or script, and default to using it with a notifies/subscribes
action :reconfig attached to the template that delivers the response_file.
--
Aaron Peterson <
>
Opscode Technical Evangelist
--
Aaron Peterson <
>
Opscode Technical Evangelist
Archive powered by MHonArc 2.6.16.