Issue 1267 - Provide a way to run some command on multiple hosts

This moves a bunch of code from kick.py into run.py, the only change was making resolveHostList call getValidHosts itself rather than getting the results as parameter. I also made the user parameter optional, as it is optional for the SSH command.

[mathias, 2014-08-25 16:21:25]

Although the changes and purpose of this patch are pretty straight-forward, I'm
not really convinced that using two script files is that beneficial.

Both the purpose and implementation of the scripts are, in my opinion, similar
enough so that a single script should suit as well - if not better. Also, the
fact that merging the scripts can reduce some code-duplications and removes the
introduction of another dependency to maintain (although an easy task in this
case), seem to support that very impression.

So, why you've decided to introduce another script file?

http://codereview.adblockplus.org/5611225295618048/diff/5629499534213120/run.py
File run.py (right):

http://codereview.adblockplus.org/5611225295618048/diff/5629499534213120/run....
run.py:134: print 'Running on %s...' % host
If all logging would be printed to >>stderr (just like it's intended to) instead
of polluting >>stdout, one could re-use the output of the command properly.

If the host information is required, one could prefix each line instead of
printing host notifications (triggered by a -p flag, for example), which is much
easier to process by scripts (|piped or via log file) or even manually
(shell/editor) later on.

This behavior could even be kept when e.g. deciding to implement parallelization
(similar to Fabric, see http://docs.fabfile.org/).

[Wladimir Palant, 2014-08-29 22:04:11]

Print all logging output to stderr

[Wladimir Palant, 2014-08-29 22:08:39]

Print all logging output to stderr

[Wladimir Palant, 2014-08-29 22:11:15]

The reason why it is two scripts is pretty simple: one is a general-purpose
script to executes commands on our servers, the other is a narrow-purpose script
to update servers. The latter is actually the one we use all the time, and I
don't want to remember the commands required (*exact* command required because
otherwise sudo won't work). On the other hand, adding its functionality to the
general-purpose script doesn't make much sense either.

What's code duplication you see there? From all I can tell, it's only the
parameter parsing - and even that isn't really the same.

http://codereview.adblockplus.org/5611225295618048/diff/5629499534213120/run.py
File run.py (right):

http://codereview.adblockplus.org/5611225295618048/diff/5629499534213120/run....
run.py:134: print 'Running on %s...' % host
On 2014/08/25 16:21:25, matze wrote:
> If the host information is required, one could prefix each line instead of
> printing host notifications

I'm not usually using scripts on the output. And there might not even be any
output - I simply want to see the current progress when running a command on
twenty servers.

> one could prefix each line

It's not that easy IMHO. Piping command output in Python while the command is
running requires a second thread - I'm not ready to go there for this simple
tool. An external tool like awk could do it as well, this adds a dependency
however. In the end, maybe I can simply pipe it into a second Python process -
but that's something to consider when I actually need this functionality.

> This behavior could even be kept when e.g. deciding to implement
parallelization

I don't think I want to go there just yet :)

[mathias, 2014-09-03 13:17:17]

LGTM.

I'd still prefer a calling scheme like "./run.py $command" instead of two
different scripts, but that's basically just a personal preference.

On 2014/08/29 22:11:15, Wladimir Palant wrote:
> What's code duplication you see there? From all I can tell, it's only the
> parameter parsing - and even that isn't really the same.
> 
>
http://codereview.adblockplus.org/5611225295618048/diff/5629499534213120/run.py
> File run.py (right):
> 
>
http://codereview.adblockplus.org/5611225295618048/diff/5629499534213120/run....
> run.py:134: print 'Running on %s...' % host
> On 2014/08/25 16:21:25, matze wrote:
> > If the host information is required, one could prefix each line instead of
> > printing host notifications
> 
> I'm not usually using scripts on the output. And there might not even be any
> output - I simply want to see the current progress when running a command on
> twenty servers.
> 
> > one could prefix each line
> 
> It's not that easy IMHO. Piping command output in Python while the command is
> running requires a second thread - I'm not ready to go there for this simple
> tool. An external tool like awk could do it as well, this adds a dependency
> however. In the end, maybe I can simply pipe it into a second Python process -
> but that's something to consider when I actually need this functionality.
> 
> > This behavior could even be kept when e.g. deciding to implement
> parallelization
> 
> I don't think I want to go there just yet :)