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

[Andrew Gross < >]

Hey All,

I wanted to recap this thread so we can make a decision on it before it gets lost in the shuffle:

Initial Pull Request Goal: Prevent failed Chef runs due to apt-get failures that can be fixed by running apt-get update

Evolved Goal: Provide some way to handle 'expected' failures.  Either per block (notification style), as a global setting, or a special block that can watch certain blocks.

Gotchas:  Don't make Chef do implicit things, aim to be explicit

On Mon, Mar 4, 2013 at 8:12 PM, Bryan McLellan < " target="_blank"> > wrote:

On Mon, Mar 4, 2013 at 12:13 PM, Adam Jacob < "> > wrote:
> Why don't we make this a resource?
>
> package "totally-sucks-devel"
>
> on_failure "run apt-get update" do
>   match /^package/
>   notifies :run, "execute[apt-get-update]"
> end
>
> Where match is a regular _expression_ that looks for names of resources.

Totally, this feels really useful, even if it could be a terrible idea still.

On Mon, Mar 4, 2013 at 2:33 PM, Kevin Keane Subscription
< "> > wrote:
> Isn't the philosophy of Chef that resources should describe the final, desired, state of the system? This resource just feels "procedural" rather than "declarative".
>
> Or am I way off on this?

I agree that the "correct" fix for apt-get issues is tracking down
what's wrong and fixing your run. For instance, if your instances are
from EC2 and your apt-cache is always stale, you should ensure that
apt-get update happens at the beginning of your run, perhaps being
very early in a base role. If you are having issues after installing a
repository, you should be using the functionality in the apt cookbook.
If you always need the latest update before a package install you have
to bite the bullet and always run apt-get update. However, in this
example it is clear that we'd solve a lot of frustration for a bunch
of people if we didn't force them to do it the ideal way, and instead
gave them options to get it fixed and get back to work.

On the other hand, it's hard to think up other situations like this
that justify a feature that someone can get themselves so far down the
wrong path with. I like the idea of handling network or mirror issues
that the tools might handle poorly.

on_failure "rotate mirrors for dumb_tool" do
  match /^execute[dumb_tool]$/
  notifies :run, "execute[swap_dumb_tool_mirrors]"
  retries 3
end

aws_timeout = 30
aws_retries = 2

on_failure "AWS API timeout" do
  match /-aws]$/
  block do
    Chef::Log.warn("Failure in #{failed_resource}, maybe an AWS issue,
pausing #{aws_timeout} seconds and retrying #{aws_retries} times")
    sleep aws_timeout
  end
  retries aws_retries
end

on_failure "github is down" do
  match /^git[our-code-/
  block do
    Chef::Log.warn("Failed to act on repository
#{failed_resource.repository} in resource #{failed_resource}, trying
internal mirror")
    failed_resource.repository.gsub(/^http:\/\/github.com\/opscode/,
"git://backup_git_mirror")
  end
end

Bryan