[[chef-dev]] Re: [[chef-dev]] Re: [[chef-dev]] Re: [[chef-dev]] new package resource action :reconfig

[Aaron Peterson < >]

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 examplehttps://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 < " target="_blank" style="color: rgb(0, 0, 204); "> >

Opscode Technical Evangelist 

-- 
Aaron Peterson <
 
 ">
 >
Opscode Technical Evangelist