On Monday, March 4, 2013 at 12:44 PM, Andrew Gross wrote:
That works pretty well, I think the previous idea sprouted from the constraint that we didnt want to have to add this block to every single package block. Unsure how to resolve that with this syntax unless we could specify global defaults for some of these things.On Mon, Mar 4, 2013 at 3:22 PM, Jesse Campbell < " target="_blank"> > wrote:or alternatively, make it a block like thing:make on_failure accept either a string or a block, and an optional set of arguments telling whether to retry and how many timesendon_failure "apt-get update", :retry_oncecassiano, i think you nailed it.make on_failure function just like an only_if/not_if/notify thing:
package "totally-sucks-devel" do
package "totally-sucks-devel" do
on_failure donotifies :run, "execute[apt-get-update]"retry true
end
end
On Mon, Mar 4, 2013 at 2:44 PM, Cassiano Leal < " target="_blank"> > wrote:I agree, but this would be easily fixed by making on_failure a resource property that takes a block as an argument instead of being a resource itself.- cassianoOn Monday, March 4, 2013 at 16:33, Kevin Keane Subscription wrote:
I didn't follow this discussion from the start, just saw this. Forgive me if I'm way off base here, but at first glance, this seems very wrong to me, the "it just feels strange" type of wrong.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?-----Original Message-----From: Adam Jacob [ " target="_blank">mailto: ]Sent: Monday, March 4, 2013 9:13 AMSubject: [chef] Re: Re: Re: Re: Re: CHEF-3930: Run apt-get update automagically if apt-get install fails
Why don't we make this a resource?package "totally-sucks-devel"on_failure "run apt-get update" domatch /^package/notifies :run, "execute[apt-get-update]"endWhere match is a regular _expression_ that looks for names of resources.AdamOn 3/4/13 9:06 AM, "Bryan McLellan" < " target="_blank"> > wrote:On Fri, Mar 1, 2013 at 11:21 PM, Jesse Campbell < " target="_blank"> > wrote:What about extending the current handler approach? Add the ability tocatch a failed resource (by name) and retry it, just like you canwith a begin/rescue.I like the concept of having an exception handler be tied to a resourceor provider, or at least be able to determine what resource or providercaused the exception, do some bits and retry.Bryan
Archive powered by MHonArc 2.6.16.