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

[Daniel P. Berrangé]

On Fri, Nov 20, 2020 at 03:41:54PM +0100, Peter Krempa wrote:
> 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.

To be fair, a key part of libvirt's value add is that it provides the
stable API to applications, insulating them from hypervisor changes.
This enables QEMU to make incompatible changes in a reasonable timeframe,
without breaking the end applications.

Of course there is a trade off here because every time QEMU changes,
libvirt gets to add back compat code to its maint burden, but the
premise is that this is still cheaper overall.

We don't want QEMU to gratuitously break things for no reason, but
if there's a compelling reason to change QEMU, libvirt is there to pick
up the pieces to protect applications.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|