10:19 p.m.
hi guys,
It's hard for me to understand why doesn't virsh command support an
optional parameter because I think omitting a parameter and offering
a default value sometimes is quite convenient.
For example:
$ virsh shutdown guest --mode acpi
The option --mode only accept string "acpi", "agent",
"initctl" and
"signal", assuming that "acpi" is the most frequently used parameter
when --mode is specified, why not just using
$ virsh shutdown guest --mode acpi
instead.
Maybe this example is not very precise, but what I mean is if there is
an option which only accepts several candidate values and one of the
value is always used when it is specified, then we can make it the
default parameter of this option. This would be convenient and save
some typing.
Of course, this can also result in ambiguity to people who is not
familiar with the command. But with the help, it won't trap one very
long, will it?
So, why doesn't virsh support this and what do you think of adding
this feature?
Thanks
Zhang Xiaohe
10:35 p.m.
On 04/25/2013 09:19 PM, Zhang Xiaohe wrote:
hi guys,
It's hard for me to understand why doesn't virsh command support an
optional parameter because I think omitting a parameter and offering
a default value sometimes is quite convenient.
For example:
$ virsh shutdown guest --mode acpi
Did you mean 'virsh shutdown guest --mode' here, with a missing trailing
argument to the --mode option?
The option --mode only accept string "acpi",
"agent", "initctl" and
"signal", assuming that "acpi" is the most frequently used parameter
when --mode is specified, why not just using
$ virsh shutdown guest --mode acpi
instead.
The default is to not specify --mode at all; if you are worried about a
mode, then there is no way for virsh to know what mode is best for you.
In this particular example, while acpi works for qemu, it does not work
for lxc; there, the best default is more likely to be initctl. Since we
can't make a different default per hypervisor without repeating all the
logic of a hypervisor in virsh, this seems like a change that's not
worth making.
Also, consider what it would take to implement optional option parsing.
Existing scripts that used --mode=acpi are immune, but scripts that
used '--mode acpi' as two arguments now have a problem - how do we know
that the user didn't intend '--mode' with its default setting, and
'acpi' as a separate argument?
Maybe this example is not very precise, but what I mean is if there is
an option which only accepts several candidate values and one of the
value is always used when it is specified, then we can make it the
default parameter of this option. This would be convenient and save
some typing.
Of course, this can also result in ambiguity to people who is not
familiar with the command. But with the help, it won't trap one very
long, will it?
I'm unwilling to make any current option that requires an argument
switch to becoming an option with an optional argument (because that in
itself introduces parser ambiguities that may break scrips written
against an older virsh). However, there IS a request to add
user-defined alias support to virsh. If you find yourself frequently
typing a given command, it would make sense to have virsh have a way to
let you define an alias that shortens the amount of typing you have to
do to get that alias. It wouldn't be default out of the box, but may be
a compromise that could help the situation you are worried about.
For virsh aliases to work, someone would have to submit patches - is
that something you are interested in writing?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
12:01 a.m.
于 2013年04月26日 11:35, Eric Blake 写道:
On 04/25/2013 09:19 PM, Zhang Xiaohe wrote:
> hi guys,
>
> It's hard for me to understand why doesn't virsh command support an
> optional parameter because I think omitting a parameter and offering
> a default value sometimes is quite convenient.
>
> For example:
> $ virsh shutdown guest --mode acpi
Did you mean 'virsh shutdown guest --mode' here, with a missing trailing
argument to the --mode option?
Sorry, I intended to say that use 'virsh
shutdown guest --mode' instead
of 'virsh shutdown guest --mode acpi'
> The option --mode only accept string "acpi", "agent",
"initctl" and
> "signal", assuming that "acpi" is the most frequently used
parameter
> when --mode is specified, why not just using
> $ virsh shutdown guest --mode acpi
> instead.
The default is to not specify --mode at all; if you are worried about a
mode, then there is no way for virsh to know what mode is best for you.
In this particular example, while acpi works for qemu, it does not work
for lxc; there, the best default is more likely to be initctl. Since we
can't make a different default per hypervisor without repeating all the
logic of a hypervisor in virsh, this seems like a change that's not
worth making.
I use this example to describe only the format, so just ignore what
mode
really means.
Also, consider what it would take to implement optional option parsing.
Existing scripts that used --mode=acpi are immune, but scripts that
used '--mode acpi' as two arguments now have a problem - how do we know
that the user didn't intend '--mode' with its default setting, and
'acpi' as a separate argument?
This does be a problem.
>
> Maybe this example is not very precise, but what I mean is if there is
> an option which only accepts several candidate values and one of the
> value is always used when it is specified, then we can make it the
> default parameter of this option. This would be convenient and save
> some typing.
> Of course, this can also result in ambiguity to people who is not
> familiar with the command. But with the help, it won't trap one very
> long, will it?
I'm unwilling to make any current option that requires an argument
switch to becoming an option with an optional argument (because that in
itself introduces parser ambiguities that may break scrips written
against an older virsh).
OK, I see.
However, there IS a request to add
user-defined alias support to virsh. If you find yourself frequently
typing a given command, it would make sense to have virsh have a way to
let you define an alias that shortens the amount of typing you have to
do to get that alias. It wouldn't be default out of the box, but may be
a compromise that could help the situation you are worried about.
For virsh aliases to work, someone would have to submit patches - is
that something you are interested in writing?
My members and I currently are writing a new feature for qemu and this
needs to add an option to one virsh command. We are discussing whether
a default value can be offered with an optional parameter because one
of the values is always valid while the others are not. But now we'll
try another way.
Thanks,
Zhang Xiaohe
4231
days inactive
4231
days old
2 comments
2 participants
participants (2)
-
Eric Blake -
Zhang Xiaohe