It seems like that would still require updating every resource with that bit of code.I prefer to have a central location for me to explicitly define this behavior and allow it to "do what I mean". Having the default be to have Chef refuse to cross the line and implicitly do what I expect it to do is fine, but I do believe there should be an option I can turn on that will tell Chef "Yeah, I know you're doing more than I'm explicitly telling you to do each and every time I configure individual resources, but I'm okay with that because this is the behavior I expect and I'd prefer to to the equivalent of going to my coffee vendor and ordering 'The usual' instead of having to say every time 'Large coffee, 3 creams, 1 sugar' because that's always what I'm going to want unless I explicitly tell you differently."On Thu, Feb 28, 2013 at 1:50 PM, Jeffrey Hulten < " target="_blank"> > wrote: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
" target="_blank"> 206-853-5216
Skype: jeffhulten
On Feb 28, 2013, at 7:10 AM, Andrew Gross < " target="_blank"> > 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 < " target="_blank"> > 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 < " target="_blank"> >
> Reply-To: " " target="_blank"> " < " target="_blank"> >
> Date: Wednesday, February 27, 2013 8:07 PM
> To: chef < " target="_blank"> >
> 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) <lusis.org+ " target="_blank"> > 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?
>
>
>
Archive powered by MHonArc 2.6.16.