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

[Dennis Klein < >]

>>> I see 3 options for idempotency:
>>> 
>>> 1. invoke the reconfiguration only if the :response_file has changed
>>> - disadvantage: non-chef misconfigurations of a package will go unnoticed.
>>> 2. rely on idempotency of the reconfiguration facility on the specific 
>>> platforms
>>> - disadvantage: if the platform implementation changes, idempotency may 
>>> not be given any more.
>>> 3. implement logic which retrievs the actual configuration values from 
>>> the node and decide, if a reconfiguration is needed. (maybe even put the 
>>> retrieval logic to ohai)
>>> - disadvantage: intense coding necessary, in the case of apt, extra 
>>> packages need to be installed to be able to retrieve config values or you 
>>> have to reimplement a database client as part of the provider ...
>>> 
>>> So far I only implemented the :reconfig action for the apt provider. 
>>> Therefore I chose option 2, because dpkg-reconfigure is already 
>>> idempotent.
>> 
>> https://gist.github.com/1129625 ;(this is only a hack, but to get an idea 
>> about how it could look like)
> 
> Ok.
> dpkg-reconfigure is idempotent but from what i read the resource will
> be set updated_by_last_action on every run. (dpkg-reconfigure always
> returns 0 whether changes have been made or not)
> 
> I'd say option 3 is the only way to go. What extra packages are you
> thinking of ?

I was thinking of the package debconf-utils which is not installed by default 
and which comes along with a command debconf-get-selections. But one could 
also work with debconf-show I guess.

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 ?!

If we would go with option 3, what do you think about putting the config 
value retrieval logic into ohai and the comparison logic only into the 
package providers (Could this work with chef-solo too?!).

--
Dennis