fab-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fab-user] I bet it would be pretty to do transaction semantics but


From: Jeff Forcier
Subject: Re: [Fab-user] I bet it would be pretty to do transaction semantics but it sure would be nice
Date: Thu, 23 Jul 2009 16:57:22 -0400

On Thu, Jul 23, 2009 at 4:34 PM, Matthew Wilson<address@hidden> wrote:

> How are other people handling error situations?  It seems like a run
> job immediately aborts.  Would it make sense to support a callback
> that executes on failure?

My guess is that it's not come up much before because it's just too
daunting in many cases. Think about the wide array of possible state
changes you can effect with a run()/sudo()/put() call, then multiply
that by the number of calls in even a short task. What if they have
interplay with each other? Each callback would have to consider
everything that came before it. And so forth.

I'd wager the safest thing to do would be to ensure that your tasks
are factored out into chunks as atomic as possible, and check the
.failed attribute of run()/sudo() return values when necessary (and
revert if necessary) within those atomic subroutines. In this case,
having a callback might actually not even work well, because the
callback would be run in a different scope from the earlier
environment so you'd lose any state you may have wanted to accumulate
(though I guess one could do something funky like pass in a copy of
locals().)

That said, I'm definitely all ears for ideas on how to make it easier
to write safer Fab tasks, either on the writing or the error handling
side.

-Jeff




reply via email to

[Prev in Thread] Current Thread [Next in Thread]