"Dr. David Alan Gilbert" <dgilb...@redhat.com> writes: > * Han Han (h...@redhat.com) wrote: >> However, another important question is: how can we avoid such undocumented >> incompatibility appears again? > > The reboot-timeout one was accidental - it was a documented qemu > feature; just no one noticed it when the input check was added.
Yes. Mistakes happen. Integration tests can catch them. Perfection is impossible there as well, though. > Officially if we actually want to deprecate a feature we should actually > follow qemu's deprecation guidelines. Yes. >> I can show another case caused by such incompatibile change: >> https://bugzilla.redhat.com/show_bug.cgi?id=1745868#c0 >> >> For the qemu devices, attributes, values, qmp cmds, qmp cmds arguments used >> by libvirt, could we get a way to inform libvirt >> that an incompatibile qemu change is coming, please update libvirt code >> ASAP to adjust to that change? >> Or another way that is more gently: popping up the warning of depreciation >> instead of dropping it, and then drop it in the version >> after next version. > > Yes that should happen; No argument. The question is how. I'm working on making it easier to do and easier to consume for QAPI interfaces, i.e. most of QMP. > with deprecated devices it's easier than more > subtle features like command line things; I'm not sure how that gets > introspected. I thought libvirt already asked qemu for a list of > devices, so I'm confused why libvirt didn't spot it before starting the > VM in 1745868. Command line isn't really introspectable (see my KVM Forum 2017 talk). That said, the list of devices *is* introspectable with QMP: {"execute": "qom-list-types", "arguments": {"implements": "device", "abstract": false}} I'm not sure what exactly goes wrong in RHBZ 1745868.
