Re: [libvirt] [RFC 0/7] Warn at runtime when deprecated features are used

Picking up the thread again from here because it looks like as sensible a point as any. On Tue, 2018-10-02 at 18:26 +0200, Andrea Bolognani wrote: I'd say at this point it's fair to conclude that the consensus among libvirt developers is to stick to the existing compatibility promise and thus never deprecate, let alone drop, features; the question of whether defaults could ever change hasn't been answered in such a clear-cut manner, as far as I can tell, but it's also somewhat less relevant because I think we can all agree that having a single default value is simply not going to cut it these days. So applications are supposed to provide explicit values, obtained through libosinfo, so that they will keep working as other parts of the stack change around them; this will, however, not be enforced in any way but rather encouraged through documentation. This is a sensible enough plan, but it fails to address one important scenario: people using virsh directly to script changes and other operations on their guests - see above for an example of how that can end up not working as expected. Since virsh itself is basically just exposing raw libvirt APIs, it doesn't and shouldn't have much logic of its own, plus it falls under the same stability guarantees as the library itself, so we can't easily change it. The obvious solution is to have a *different* command line client that can alter guests the same way virsh can, but is not shipped as part of libvirt and can thus link against libosinfo as well as not having to follow the same strict stability guarantees. Pavel helpfully pointed out that such a client already exists: it's called virt-xml and it's part of virt-manager. It needs a few tweaks before it can really fit the bill, but once that's been taken care of you should be able to use something like $ virt-xml \ myguest \ --os-variant fedora28 \ --add-device \ --network network=default and get a virtio-net device, as you should, instead of rtl8139. Actually accepting --os-variant is the missing bit, but it should be fairly easy to do; not only that, but the existing proposal to store libosinfo metadata in the guest XML during installation has the potential to make even that entirely unnecessary! For installation you'll obviously want to use virt-install, but that's the case already since actually installing a guest from scratch using 'virsh define' is just madness :) IIUC the use case of importing an existing guest image without booting the guest at the same time is not covered, but once again that's only a bugfix away. So once we have these changes in place, command line users can be pretty much completely isolated from libvirt defaults, just like virt-manager and oVirt and Nova users. Then it will be up to us to actually advertise these alternatives and push users away from virsh[1] and towards them. I wonder if showing a message suggesting to use virt-xml instead when 'virsh edit' or 'virsh attach-device' are called would be considered acceptable at that point? [1] Only where it makes sense, of course: 'virsh start' and similar, for example, don't really need an alternative. -- Andrea Bolognani / Red Hat / Virtualization