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

[Jeffrey Hulten < >]

Perhaps being able to specify, for any given resource 

on_failure_notifies :action, "resource_type[name]"), :immediately_and_retry

would allow both problems to be solved?
--
Jeffrey Hulten
Principal Consultant at Automated Labs

 
  206-853-5216
Skype: jeffhulten

On Feb 28, 2013, at 7:10 AM, Andrew Gross 
<
 >
 wrote:

> The issue here seems to be a conflict between the general Chef philosophy 
> and what a generally sane default.  I noticed similar behavior in
> 
> http://tickets.opscode.com/browse/CHEF-3734
> 
> Where the `git` resource was behaving in a similar way to the `deploy` 
> resource, even though that was not what was explicitly asked for.  In this 
> case it looks like the change is leaning towards making `git` do explicitly 
> what was asked and no more. 
> 
> It feels similar to the conflict when writing an API, you want to have a 
> layer where you have definitions that provide explicit behavior so you can 
> manipulate the system.  At the same time though you want to provide a good 
> interface to the end user and give them a smooth interface that avoids many 
> of the pitfalls associated with inexperience.  Normally this is solved by 
> just writing two libraries and having the user facing library wrap the 
> explicit one, however Chef doesn't seem to quite fit in as either choice 
> (You could also argue that Chef is the wrapper library and the OS is the 
> lower level API). 
> 
> On a side note:
> 
> I like the idea of having a generic system for handling recovery from 
> simple issues. I can see the logic about not having Chef do implicit 
> changes that may be unexpected.  A downside to using an explicit retry hook 
> for something like packages is that you end up having to write it in to 
> every block, making your recipes seem very cluttered. It would be nice if 
> along with a retry system there was a simpler way to modify defaults for a 
> provider without needing to monkey patch the resource definition or 
> wrapping the call with your own LWRP.
> 
> Andrew
> 
> 
> On Thu, Feb 28, 2013 at 12:43 AM, Adam Jacob 
> <
 >
>  wrote:
> 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 
> <
 >
>  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) 
> <
 >
>  wrote:
> On Wed, Feb 27, 2013 at 6:44 PM, Andrea Campi
> <
 >
>  wrote:
> >
> >
> >
> > On Thu, Feb 28, 2013 at 12:19 AM, Bryan McLellan 
> > <
 >
> >  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
> >> <
 >
> >>  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?
> 
> 
>