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: Christian Vest Hansen
Subject: Re: [Fab-user] I bet it would be pretty to do transaction semantics but it sure would be nice
Date: Fri, 24 Jul 2009 08:56:05 +0200

My tasks are written such that the commands I execute on the servers
are "effectively idempotent" to the greatest extent possible, so I can
rerun them if I need to. In some cases I might decide to catch the
SystemExit exception that utils.abort raises, even though it's a
butt-ugly practice.

Doing things this way will most likely not work for everybody. I
suppose my fabfiles are pretty simple and straight forward compared to
what other people are doing.

Jeff, have you heard about the condition system in Common Lisp? I was
thinking that it may be possible to model a poor mans version of it
with clever use of context managers and exceptions. Although probably
a foreign concept to most pythonistas, it would at least be a very
powerful way of dealing with faults. Just thinking out aloud. Could
also be that it's too difficult to get right or too much work.

On Thu, Jul 23, 2009 at 10:57 PM, Jeff Forcier<address@hidden> wrote:
> 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
>
>
> _______________________________________________
> Fab-user mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/fab-user
>



-- 
Venlig hilsen / Kind regards,
Christian Vest Hansen.




reply via email to

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