fab-user
[Top][All Lists]
Advanced

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

Re: [Fab-user] road to 0.1.0


From: Jeff Forcier
Subject: Re: [Fab-user] road to 0.1.0
Date: Sat, 12 Jul 2008 12:56:51 -0400

> I'm not really sure how capture in capistrano works. On the surface,
> it looks like run, except it returns stdout of the first host - which
> dosn't sound particularly clever to me.
>
> [...]
>
> Hmm... this one's a tough cookie. #3 might indeed be the best way to
> do it. But if we return stdout as a string, which host do we return it
> from?

Yup, that's the case in Capistrano, and is actually one of the reasons
I realized that the current execution model of Cap/Fabric doesn't jive
well with the idea of capturing output; and that's what led me to the
stuff I outlined in the programmer's doc about "serial" vs "parallel"
approaches.

The way things are now, where each operation executes in serial and
'broadcasts' to all hosts one step at a time, capturing can only
really grab one arbitrary host's output, which doesn't seem too useful
to me unless all hosts will have the same output.

In the 'parallel' approach, where each *command* executes per-host
(and thus each operation is also per-host) capturing makes more sense
because you can deal with the output one host at a time. This is, of
course, my whole drive for this, the ability to -- per-host -- say
"see if grep username /etc/passwd gets me anything, if so do X,
otherwise do Y".

I've been avoiding actually taking a stab at hacking up this parallel
approach, but I think I should go ahead and give it a try, because I
think the base-case here is that we only offer capture for parallel
execution. Having it for serial execution would be "nice" for the
cases where it works well, but it's not the primary use case IMHO.

-Jeff




reply via email to

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