Re: [libvirt] virt-admin commands aliases
On Mon, 2016-09-05 at 17:37 +0200, Erik Skultety wrote:
Hi there,
after my presentation at KVM Forum, it was pointed out from the audience
Disclaimer: I'm the audience in question :)
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.
I'm sorry for not paying enough attention at the time and
for not raising the issue while the series was still undergoing
review. If I had, we wouldn't need to have this discussion :(
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).
This is very tempting, but I'm not sure we can actually get
away with it.
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)
This seems like a fair solution, but note that I haven't
looked at the patch implementing it yet - I might change my
mind once I did 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
I feel very strongly against this option.
Not only "clnt" is four letters long, as opposed to the three
letters of both "srv" and "dmn", I also think both "clnt"
and
"dmn" are absolutely unsightly and have no place in a private
API - much less in a public one.
Not to mention that we will probably end up adding more
entitites, that will have to be shortened in the same way,
quite possibly with suboptimal results.
4) leave it as is if such a consensus is reached and accepted
I guess this does no need any additional comments.
I feel *even more strongly* about this one :)
With all I've written above agains "clnt" and "dmn", I'd
rather have those instead of the current inconsistent naming
convention.
--
Andrea Bolognani / Red Hat / Virtualization