[libvirt] virt-admin commands aliases

[Andrea Bolognani]

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