On Thu, Apr 06, 2006 at 02:44:41PM +0200, Karel Zak wrote:
> On Thu, Apr 06, 2006 at 08:40:17AM -0400, Daniel Veillard wrote:
> > On Thu, Apr 06, 2006 at 02:37:37PM +0200, Karel Zak wrote:
> > > On Thu, Apr 06, 2006 at 11:46:57AM +0200, Jim Meyering wrote:
> > > > So, now I can use something like this to get a list of domain names:
> > > >
> > > > virsh list | tail -n +4 | awk '{print $2}'
> > > >
> > > > Is there some easier way?
> > >
> > > I think we can add some options to the list command:
> > >
> > > --noheader
> > > --nodom0
> > > --cols=name,id,state,maxmem,usemem,....
> > >
> > > without these options it will use default (current) format. I've
> > > already thought about this solution for the others commands (e.g.
> > > dominfo). I think this is a way how make it useful in scripts.
This raises the question of what the primary intended use case of virsh
is / should be. Currently I see it as being an interactive administrator
tool, and as such it should be focused on optimal presentation of the data
for a user to understand.
Now, I don't disagree that there is a need for something that is easy to
script in the shell, but if we are going to make virsh easier to script
we should be careful not to compromise the primary use case of interactive
administrator control. Conversly we must be careful not be end up with the
presentation focused output becoming a defacto API, because there is much
pain & suffering that way - simple changes to improve user experiance would
end up breaking scripting. Another example - gettext translations of the
output fields could break scripts which are grokking for English strings.
So, I'd say, rather than add a whole range of extra command line options
for tweaking the existing administrator presentation-focused output, we
should instead add a single '--batch' option. This would activate a completely
separate presentation mode tailored explicitly to the needs of scripts. It
would have a formal structure for outputting data, perhaps a series of rows
expressed as 'key:value' pairs, or a single line in CSV format, or some other
easily shell-parsable format.
Finally, while I think it is useful to have the ability to script common
tasks from the shell, we shouldn't worry about getting every single little
detail covered. We already have two very simple scripting APIs for interacting
with libvirt - Python & Perl which will be far more powerful for automation
that shell+virsh+awk could ever be.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|