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


Chronological Thread 
  • From: Dennis Klein < >
  • To:
  • Cc:
  • Subject: [[chef-dev]] Re: [[chef-dev]] new package resource action :reconfig
  • Date: Sat, 6 Aug 2011 20:25:05 +0200


On Aug 6, 2011, at 7:43 PM, 

 wrote:

> Dennis Klein 
> < >
>  writes:
> 
> Hi,
> 
>> I have written a patch which introduces a new action :reconfig to the 
>> package resource. Because it is a (non-breaking) change to the dsl api I 
>> think it should be discussed first before I file a new ticket.
>
>> Background: The package resource already has a :response_file attribute, 
>> which can be used to preseed configuration values for a package. In the 
>> case of the apt provider this preseeding only happens when the :install 
>> action is invoked, for reconfiguration of already installed packages its 
>> not usable at the moment. For apt, this would mean to invoke 
>> dpkg-reconfigure. I don't think it is elegant implementing it in the 
>> :install action - therefore I invented the :reconfig action.
>
>> I intend to also resolve http://tickets.opscode.com/browse/CHEF-294 which ;
>> would be even more powerful together with a reconfiguration mechanism.
>
>> What do you think? Do you like the introduction of the :reconfig action or 
>> would you implement this in a less invasive way? We could also discuss the 
>> naming of the action, I obviously inherited :reconfig from the debian 
>> world (see dpkg-reconfigure).
> 
> Yes, i think it's a good idea, how do you plan on making it idempotent ?
> Have you written a new debconf resource and provider that the apt
> package resource would require ?
> 
> -- 
> Laurent

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.

--
Dennis


Archive powered by MHonArc 2.6.16.

§