Re: [PATCH 5/6] qapi: Add support for aliases

[Peter Krempa]

On Fri, Nov 13, 2020 at 10:46:02 +0100, Kevin Wolf wrote:
> Am 12.11.2020 um 19:34 hat Eric Blake geschrieben:
> > On 11/12/20 11:28 AM, Kevin Wolf wrote:
> > > Introduce alias definitions for object types (structs and unions). This
> > > allows using the same QAPI type and visitor for many syntax variations
> > > that exist in the external representation, like between QMP and the
> > > command line. It also provides a new tool for evolving the schema while
> > > maintaining backwards compatibility during a deprecation period.
> > 
> > Cool! Obvious followup patch series: deprecate all QAPI members spelled
> > with _ by making them aliases of new members spelled with -, so that we
> > can finally have consistent spellings.
> 
> Ah, that's a nice one, too. I didn't even think of it. Another one I'd
> like to see is deprecation of SocketAddressLegacy.
> 
> There is one part missing in this series that we would first need to
> address before we can actually use it to evolve parts of the schema that
> are visible in QMP: Exposing aliases in introspection and expressing
> that the original name of something is deprecated, but the alias will
> stay around (and probably also deprecating an alias without the original
> name or other aliases).
> 
> If we can easily figure out a way to express this that everyone agrees
> with, I'm happy to include it in this series. Otherwise, since the first
> user is the command line and not QMP, I'd leave that for the future.
> 
> For example, imagine we have an option 'foo' with a new alias 'bar'. If
> we just directly expose the alias rule (which would be the simplest
> solution from the QEMU perspective), management will check if the alias
> exists before accessing 'bar'. But in the final state, we remove 'foo'
> and 'bar' is not an alias any more, so the introspection for 'bar' would
> change. Is this desirable?
> 
> On the other hand, we can't specify both as normal options because you
> must set (at most) one of them, but not both. Also exposing things as
> normal options becomes hard with wildcard aliases (mapping all fields
> from a nested struct), especially if unions are involved where some
> options exist in one or two variants, but not in others.
> 
> Given this, I think just exposing the alias rules and letting the
> management tool check both alternatives - if the alias rule or the
> future option exists - might actually still be the least bad option.
> 
> Hmm, I guess I should CC libvirt for this discussion, actually. :-)

I can see how that simplifies things for qemu in the long run, but to be
honest, if you then deprecate the old name, libvirt will need to add a
translation table for it. Either explicit by detecting the new name and
adapting the code or by adding a lookup table or something. This would
be needed as if you then remove the alias itself we'd no longer be able
to use it, so I'm not entirely a fan of it, especially the deprecation
bit.