Re: [PATCH] virsh: add aliases 'boot', 'stop', and 'restart'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/08/2012 11:24 AM, Daniel P. Berrange wrote:
> On Thu, Nov 08, 2012 at 10:51:14AM -0500, Dave Allan wrote:
>> On Thu, Nov 08, 2012 at 03:24:07PM +0100, Daniel P. Berrange wrote:
>>> On Mon, Nov 05, 2012 at 12:59:16PM -0700, Eric Blake wrote:
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=873344 suggested that
>>>> the grouping 'boot', 'shutdown', 'reboot'; as well as the grouping
>>>> 'start', 'stop', 'restart'; might be easier to remember than the
>>>> current mix of 'start', 'shutdown', 'reboot'.
>>>>
>>>> * tools/virsh-domain.c (domManagementCmds): Add other command names.
>>>> * tools/virsh.pod (start, shutdown, reboot): Document the aliases.
>>>> ---
>>>>
>>>> This patch documents both spellings.  An alternative would be to
>>>> leave the alternate spellings as hidden aliases (virsh has support
>>>> for that), but still mention them in virsh.pod (see how we did an
>>>> alias for nodedev-dettach, for reference).
>>> NACK to this patch. I think the current command names are good.
>>> Creating duplicates will make life worse. First, it creates
>>> divergance from the similarly named commands for networks,
>>> storage and other objects. It also means scripts written again
>>> the new commands will not work with existing libvirt.
>>>
>>> I actually think that shutdown & reboot are *better* names
>>> than restart and stop.
>>>
>>> If we wanted to replace any existing names, then the 'create'
>>> and 'destroy' names are the ones to replace, and for those I
>>> would expect to use 'boot' and 'stop'. I still don't thin
>>> we should do that either, due to creating inconsistency with
>>> other commands.
>> IMO this is fundamentally an aesthetic question here that's not going
>> to be solved by debate, however, from the comments so far, the patch
>> seems to have a fair amount of support.  DV, perhaps you could weigh
>> in with your opinion?
> Since this is an aesthetic question, even adding this patch is not going
> to solve it. It is a fact of life that there are a huge variety of names
> that could be used - adding more & more aliases is not a solution. You
> can never satisfy everyone's desired name choice. You just have to pick
> one name and stick with it consistently.

I'm putting my vote with Dan on this (Just to be clear, my original
message in this thread was written in the spirit of "well, if you're
going to do this, then at least make sure what you're doing is
explicitly documented").

It's often a painful exercise to try and come up with the "best" name
for any particular operation, but once you've got a name, you've got a
name. After that, the truths are:

1) Multiple names for the same thing leads to confusion (which is what
prompted my earlier comment saying that the new names needed to be
clearly marked as synonyms).

2) There is no end to the new names that could be thought of as "better"
when taken in some particular context, or by some particular person.

3) If some action is named "foo-x" for foo objects, then a similar
action on fi objects should be named "fi-x" if at all possible. Maybe
"x" isn't the most appropriate name in the context of foo or fi, but
following a single model makes it easier to remember.

I know virsh isn't considered to be as strict of an environment as the
libvirt API proper, but we still need to be mindful of both backward
compatibility and of namespace pollution leading to confusion.

(If the current names bother you, you could just think of it from the
point of view of someone who has absolutely no knowledge of English, and
sees the command names as opaque cookies that produce the desired result.)

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]