[Fab-user] Re: Fabric

[Christian Vest Hansen]

Hi Jeff,

I'll be CC'ing the list here and hope you don't mind (it does not
sound like you do).

I indeed have noticed your fork from 7 days ago, and been wondering
what you were doing with it - especially since I found out you're also
co-authoring a python book :)

As you've guessed, I've already reviewed your changes and they are
indeed nit picking, but I don't find that offensive at all - it's the
kind of silly little mistakes that we make all the time and that only
other peoples eyes are able to catch.

I don't have a "game plan" per se, but I'm a bazaar minded person and
I will merge changes I find to my liking (as soon as I figure how to
do that, exactly), and if someone demonstrates that they can make good
changes that doesn't break everything, then I don't mind adding them
as a contributor - if they want to.
I currently have two git repositories; one on nongnu.org and the other
on github, and I'm manually keeping the two in sync. Even though the
nongnu repo is declared the "main" one, I think it is easier to do
collaborative development on github.

>  My interest in Fabric is driven by sysadmin needs, such as deleting a
>  single user across many systems (no LDAP sadly). I've toyed with
>  Capistrano, but it doesn't quite align with how I want to do things.
>  Specifically, it executes commands in parallel, which prevents any
>  sort of logic, e.g. "check /etc/passwd, if user exists, do X, and if
>  their homedir is larger than Y, stop, otherwise tar.gz and copy
>  locally" and so forth.
>
>  Jamis' answer to this for Capistrano is "write a shell script

This is a troublesome subject. For instance, get this: with "rolling"
fab_mode, commands run in parallel, while operations run serially.

As an example to show what I mean by that gibberish, consider a
fabfile that connects to two hosts: 127.0.0.1 and localhost, and has a
command like this one:

def funky_roll():
  "Show funky rolling behaviour"
  run("echo A $(fab_host)")
  run("echo B $(fab_host)")

Then, when you run that, it will print this:

[127.0.0.1] run: /bin/bash -l -c "echo A 127.0.0.1"
[127.0.0.1] out: A 127.0.0.1
[localhost] run: /bin/bash -l -c "echo A localhost"
[localhost] out: A localhost
[127.0.0.1] run: /bin/bash -l -c "echo B 127.0.0.1"
[127.0.0.1] out: B 127.0.0.1
[localhost] run: /bin/bash -l -c "echo B localhost"
[localhost] out: B localhost

This is what "rolling" fab_mode means, and it makes it hard to do any
complex logic in the python code, if that is what you want. The
"fanout" mode was intended to also run the operaitons in parallel, but
I'm getting into the deep end of paramiko and can't figure out how to
get it right. It would be possible to add a third mode that runs the
commands in serial, but doing so would require a refactor of how this
mode system is put together - which isn't an intirely bad idea, but it
will probably take a little while to get right.



On 6/22/08, Jeff Forcier <address@hidden> wrote:
> Hey Christian,
>
>  Thanks for writing Fabric!
>
>  Just dropping you a personal note (wasn't sure this was list-worthy)
>  about my Github fork of Fabric. You've probably seen the few changes I
>  just made -- I hope they aren't offensive! Partly due to being a new
>  Git user, I'm treating my fork as if it were my own project, at least
>  to a small degree -- hence these nitpicky changes I've been making as
>  I read over the source code.
>
>  Do you have a game plan for Fabric's future development, in terms of
>  collaboration with myself or anyone else who contributes (via Github
>  or otherwise)? I'm new to open source collaboration of this level
>  (only been a user/bug submitter/IRC support person) and don't want to
>  step on any toes. Obviously I *could* completely fork it as it's GPL,
>  but I doubt anyone really wants that, hence my query :)
>
>
>  My interest in Fabric is driven by sysadmin needs, such as deleting a
>  single user across many systems (no LDAP sadly). I've toyed with
>  Capistrano, but it doesn't quite align with how I want to do things.
>  Specifically, it executes commands in parallel, which prevents any
>  sort of logic, e.g. "check /etc/passwd, if user exists, do X, and if
>  their homedir is larger than Y, stop, otherwise tar.gz and copy
>  locally" and so forth.
>
>  Jamis' answer to this for Capistrano is "write a shell script, copy to
>  remote machine, run with Cap" which seems inefficient to me, not to
>  mention the hassle of keeping the remote scripts sync'd with the
>  master copy, and littering remote homedirs with extra files.
>
>  I haven't finished grokking all of your code but it sounds like you've
>  at least considered the issue of different execution models (e.g.
>  fab_mode being "rolling" or "fanout") which gives me hope for Fabric
>  :) And, certainly, if I misunderstand the intent of fab_mode, Fabric
>  is small and clean enough that I'd feel comfortable trying to update
>  it to have the necessary functionality -- not the case with Cap which
>  is a bit bigger. Not to mention Cap is written in Ruby which I'm not
>  terribly good at yet, and as you've pointed out, still hampered by its
>  past and occasional wonkiness.
>
>
>  OK, this is long enough -- sorry to babble! Hope this finds you well,
>  and looking forward to future collaboration :)
>
>  Regards,
>  Jeff F.
>


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