[chef] Re: Re: Re: Re: Re: Re: Re: CHEF-3930: Run apt-get update automagically if apt-get install fails

[Adam Jacob < >]

Yeah, I'm not a huge fan, for the same reason – we move from you being explicit, to our making decisions about behavior.

Adam

From: Jesse Nelson < "> >
Reply-To: " "> " < "> >
Date: Wednesday, February 27, 2013 8:07 PM
To: chef < "> >
Subject: [chef] Re: Re: Re: Re: Re: Re: CHEF-3930: Run apt-get update automagically if apt-get install fails

I also feel like this is crossing the line. Where now we are doing something that we weren't asked to do simply because we think we know what you want. What happens if that is exactly what a user doesn't want. Tho I can't see why an apt-get update would be a bad thing or break anything on the surface. It just smells bad. If it is to be implemented it has to be an optional disable.

On the Side note I like the idea of error callbacks for providers or retry hooks. Something we could code at a high level for some providers to do when failure happens to try to recover. This was brought up and then dismissed, but I could see there being some interesting uses.  This being one of them. 

On Wed, Feb 27, 2013 at 4:24 PM, Pete Cheslock < " target="_blank"> > wrote:

I would be +1 for this - in a previous life we had to often run apt-get update two or three times in a run just to cover edge cases when a solution like this could have helped us or made things as least less repetitive during a chef run.

-Pete

On Wed, Feb 27, 2013 at 7:20 PM, John E. Vincent (lusis) < " target="_blank">lusis.org+ > wrote:

On Wed, Feb 27, 2013 at 6:44 PM, Andrea Campi
< " target="_blank"> > wrote:
>
>
>
> On Thu, Feb 28, 2013 at 12:19 AM, Bryan McLellan < " target="_blank"> > wrote:
>>

Is anyone opposed to the idea of it simply being a flag, that in the
case of a missing package, apt-get update or yum update is called and
a single retry is performed? That would likely solve 95% of the
problems I have when this happens.

>> On Wed, Feb 27, 2013 at 6:05 PM, Andrea Campi
>> < " target="_blank"> > wrote:
>> > What about making it opt-in / opt-out with an attribute?
>> > I don't much care which way the default is, but it would sure be nice to
>> > have the option.
>>
>> It would have to be a global attribute and the only established
>> pattern we have for that is Chef::Config options. These can kind of be
>> managed by templatizing the client.rb (e.g. chef-client cookbook) but
>> it's less of a "flag" than would be convenient for this sort of thing.
>>
>> The reason it can't be a resource attribute is if you want it the
>> other way around, you're populating "auto_update true/false" in every
>> package resource in every cookbook if you want it the other way
>> around.
>
>
> D'oh, for some reason I was thinking "cookbook".
>
>>
>> But yeah, it feels awesome. Of course the apt package provider should
>> help me with my apt-cache! We also felt it violates a Chef Law, but
>> none of us could name it.
>>
>
> Yeah, it feels a bit "do what I mean", but in this case I think that's quite
> reasonable.
>
> Playing devil's advocate, how will that work with cookbooks that use
> apt_repository, which runs apt-get update ?
> Worst case there will be more than one apt-get update in a single run (and
> that probably only if the package is not there for real).
> Can you think of other edge cases?