[Libvir] Re: virsh outputs to stderr(?!) why not stdout
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.
Hum, why not discussing this on the libvir list ? Others may have soem ideas too and this may promote virsh usage a bit ;-)
Fixed :-) -- Karel Zak <kzak@redhat.com>
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 -=|
On Thu, Apr 06, 2006 at 02:18:10PM +0100, Daniel P. Berrange wrote:
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
It's already possible use it as interactive tool ("virsh" without any option) and non-interactive (e.g "virsh list").
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
Agree. I think the example above with the list command doesn't discredit interactive mode.
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.
This is pretty common for all commands, the solution is use "LANG=C" in shell scripts.
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.
Is there any example where any UNIX command use this way? (It doesn't mean that I disagree with you, but the virsh shouldn't be like from foreign planet:-). IMHO it will be better use --fieldsep=<foo> and --recordsep=<bar> global options rather than hardcode there CSV or key:value 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.
Agree. Karel -- Karel Zak <kzak@redhat.com>
On Thu, Apr 06, 2006 at 04:18:40PM +0200, Karel Zak wrote:
On Thu, Apr 06, 2006 at 02:18:10PM +0100, Daniel P. Berrange wrote:
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
It's already possible use it as interactive tool ("virsh" without any option) and non-interactive (e.g "virsh list").
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
Agree. I think the example above with the list command doesn't discredit interactive mode.
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.
This is pretty common for all commands, the solution is use "LANG=C" in shell scripts.
And add several more environment variables to get predicatable date formatting, timezone settings, etc. I think it would make it simpler & more reliable for people scripting to have a single --batch script which gave a formatting which we can guarentee to be consitent.
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.
Is there any example where any UNIX command use this way? (It doesn't mean that I disagree with you, but the virsh shouldn't be like from foreign planet:-).
I don't think it'll make it look like its from a foreign planet - simple lines of key:value pairs are pretty command for text based values, eg /proc/cpu_info. I also don't think some of the comparable existing UNIX tools are a particularly good example. For example, I know of 3rd party monitoring software which used sar, iostat & friends to collect system performance metrics. Which worked fine, until a point release of sysstat changed the presentation format. sar did actually used to have a formal batch mode command line switch for doing sensible formatting, but they removed it in latest release !
IMHO it will be better use --fieldsep=<foo> and --recordsep=<bar> global options rather than hardcode there CSV or key:value format.
I'm not convinced that providing customizeable field separators is better, because it puts a burden on the caller to guess at what field separator is unambigous wrt to the data being output. It make look like ':' is a safe separator on their current machine, but if someone were to create a VM with ':' in its name, then the script would go wrong. I think it'll lead to a more reliable tool if we just designate one separator & guarentee that it will be safe - either because we know the valid characters for each field, or by defining some escaping scheme that will be applied. The real issue being addressed by options such as '--noheader', '--fieldsep', '--cols', etc is to try and change the output into something predictable. While options for customiziing various aspects of output may or may not be useful features own right, they don't really satisfactorily address the real goal here which is predictable output formatting, to enable reliable isimple and reliable scripting. A single --batch flag with formally defined sematnics would satisfy the goal of making scripting reliable. 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 -=|
participants (2)
-
Daniel P. Berrange -
Karel Zak