Re: virt-admin commands aliases

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

 



On Tue, Sep 06, 2016 at 09:02:19AM +0200, Erik Skultety wrote:
On 05/09/16 19:48, Daniel P. Berrange wrote:
On Mon, Sep 05, 2016 at 05:37:07PM +0200, Erik Skultety wrote:
Hi there,

after my presentation at KVM Forum, it was pointed out from the audience
that we might think about doing something about the naming of the
virt-admin's comands, since there is some sort of inconsistency: srv-
vs. client- vs. dmn- (not merged yet). When I sent patches to upstream I
already knew that the naming was not optimal, but I didn't come up with
anything better so I hoped that the reviewer might think of something
better which unfortunately did not happen.

Anyway, there are multiple options how this can be approached but I'm
not 100% satisfied with neither of them:

1) rename the commands completely
Although clean, obviously this is the non-preferred option because this
would break any backwards compatibility however, I think there is a fair
chance that people haven't actually started using it yet (although that
might change between 7.3 and 7.4).

2) create aliases for non-abbreviated forms of the commands
That way, srv- would become server- and dmn- would become daemon-.
However, by doing this we'll end up with 6 almost identical entries in
the commands structure which might be error-prone once we decide to
add/create&add a flag to the command primitive, since the flag would
have to be added both to the alias and to the original (unlikely, but
possible that someone might forget about that)

3) abbreviate client- to something like clnt-
Identical to the above except for the amount of duplicate entries which
would be reduced to 2

4) leave it as is if such a consensus is reached and accepted
I guess this does no need any additional comments.

I just vote for 4.

In retrospect it would have been nice to use 'server' instead of
'srv', but ultimately it isn't a functional problem.  The "solutions"
create extra code and/or inconsitency and/or break back-compat so just
aren't worth it IMHO.


Yeah, for me personally, it was either number 2 or 4 but as you write,
both of them suck in their own way and I just could not decide which one
sucked less.

Thanks for opinions guys, appreciated :)


I, honestly, would go with #2.  I know you know it, but to recapitulate;
we already have a wiring in the code for aliases, so if you change:

   {.name = "srv-list",
    .handler = cmdSrvList,
    .opts = NULL,
    .info = info_srv_list,
    .flags = 0
   },

to:
   {.name = "server-list",
    .handler = cmdSrvList,
    .opts = NULL,
    .info = info_srv_list,
    .flags = 0
   },
   {.name = "srv-list",
    .handler = cmdSrvList,
    .opts = NULL,
    .info = info_srv_list,
    .flags = VSH_CMD_FLAG_ALIAS
   },

You will have both commands, you will only see the 'server-list' in the
help and both will work.  The only thing you need to change is, that if
you add options to the commands that don't have any (yet), you need to
add the opts_srv_list to both commands.  But that's it.  For
srv-clients-list (BTW why isn't it named list-clients or client-list)
that would require no future change.  I know you mentioned that flag
changes would need to be done in both structures as well, but honestly,
thre's VSH_CMD_FLAG_NOCONNECT and VSH_CMD_FLAG_ALIAS.  And that's it.
And I don't think we'll have any new flags anytime soon.  I even dare to
say never.

But even if you don't like that, there are ways to mitigate even this
duplication.  Just make VSH_CMD_FLAG_ALIAS work as VSH_OT_ALIAS.  That
is just make the following work:

   {.name = "server-list",
    .handler = cmdSrvList,
    .opts = NULL,
    .info = info_srv_list,
    .flags = 0
   },
   {.name = "srv-list",
    .flags = VSH_CMD_FLAG_ALIAS,
    .aliased = "server-list"
   },

When parsing you'll see that it's an alias and return the opts, flags
and info for the original aliased command.  While on that, you can make
it even better; you can get rid of flags completely by just checking if
'aliased' is set.  If it is, just search for the original command and
that's it.

I'd vote for doing something like this and maybe keeping the aliases for
daemon and server added for new commands as well (that is when you add
server-make-me-a-sandwich, you also add srv- alias as well), but that's
not a hard requirement.

Just my €.02,
Martin

Erik

IOW, admit 'srv' sucks but don't change it, and ensure new server
commands continue to use 'srv' for consistency.

We can of couse use 'daemon-' as prefix for new commands, since we
have not yet released any versions using 'dmn-' as prefix


Regards,
Daniel


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

Attachment: signature.asc
Description: Digital signature

--
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]