RE: [] Re: Re: Re: new package resource action :reconfig


#1

FYI

http://tickets.opscode.com/browse/CHEF-294
http://tickets.opscode.com/browse/CHEF-2570

Dennis

-----Original Message-----
From: Aaron Peterson [mailto:aaron@opscode.com]
Sent: Mon 8/8/2011 7:32 PM
To: chef-dev@lists.opscode.com
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 d.klein@gsi.de 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 aaron@opscode.com
Opscode Technical Evangelist


Aaron Peterson aaron@opscode.com
Opscode Technical Evangelist