Re: [Fab-user] Hosts, and their usage.

[Phil Harris]

See below for comments:

2009/7/29 Jeff Forcier <address@hidden>:
> (Re-sending this due to a mailer-daemon error; apologies if it
> eventually shows up twice.)
>
> Hi Phil,
>
> On Tue, Jul 28, 2009 at 7:16 AM, Phil Harris<address@hidden> wrote:
>
>> This runs correctly (as in there are no errors), but I would like the
>> ls2 command to run on target2, at the moment it runs on target1 when
>> called from target1.
>
> Right now, Fabric's execution model is (purposefully) simple and
> pretty naive, and due to how it does things, the decorators will only
> "work" for functions invoked via the command line. This will
> definitely be beefed up in the next release -- there've already been
> some ideas/patches kicked around for various ways to expand on the
> current model, and the current simplicity is just there to provide a
> base case to build upon.
>
> In the current model, a function called via Python (instead of being
> given to the 'fab' tool) will only run once, because we don't do any
> sort of magic to change this. Additionally, the run/sudo/etc commands
> look at the value of "env.host_string" to determine what host to
> connect to (they are designed to connect to one host at a time because
> the multi-host machinery is performed by calling task functions >1
> time in a row.)
>
> Taking both of those facts together, you should be able to temporarily
> modify the value of env.host_string when calling your sub-tasks, like
> so:
>
> @roles('target1')
> def ls():
>    run('ls /tmp')
>    for host_str in env.roledefs['target2']:
>        with settings(host_string=host_str):
>            ls2()
>
> def ls2():
>       run('ls /tmp')
>
> I haven't explicitly tested this out but it should work. If your
> @roles invocation is actually >1 role name, you'd simply need another
> level of for loop iterating over those role names.
>
> Again, in the next release, there will definitely be tools available
> to do this for you in on way or another, either by adding magic (boo!)
> or adding functions named e.g. "execute(func_obj_or_str, hosts=x,
> roles=y)" (probably better.)
>
> Best,
> Jeff

Jeff,

Thanks for the response.

My main reason for using fabric was as a replacement for Capistrano.
We have a Python dominated management toolset and I was attempting to
get rid of the ruby aspect by using fabric.  All was going swimmingly
until this issue arrived and it's sort of a show stopper
unfortunately.

The example I gave was obviously simplified and the actual tasks that
run are rather more complex.  The cap scripts are used to manage
multiple clusters (8 in all, with around 40 servers between them)
which are running IBM WebSphere Portal. A real nightmare to manage
deployments on this lot I can tell you. Especially the production
servers which are required to have 99.999% uptime (not in reality tho,
just in management minds). :)

Thanks for the help tho,  and itwould be good if there was a nicer way
to manage this in fab at a future date and I'll keep my eye on it
because I really want to switch to fab.