[Fab-user] Hosts, and their usage.

[Jeff Forcier]

(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