On Wed, 4 Jul 2018 15:34:40 +0200 Kevin Wolf <kwolf@xxxxxxxxxx> wrote: > Am 04.07.2018 um 15:02 hat Cornelia Huck geschrieben: > > On Tue, 3 Jul 2018 13:32:29 +0200 > > Kevin Wolf <kwolf@xxxxxxxxxx> wrote: > > > > > > > > Has serial/gemoetry been fixed meanwhile and will it make it into the > > > > > > next release? > > > > > > > > > > I cannot find an archive that has it, but it is on the libvirt mailing > > > > > list as " [PATCH v3] qemu: format serial and geometry on frontend disk device". > > > > > Review seems done, but it has missed libvirt 4.5 which was released today. > > > > > > > > Just posted latest version here: > > > > > > > > https://www.redhat.com/archives/libvir-list/2018-July/msg00130.html > > > > > > > > It will be in the next release on ~ Aug 1st > > > > > > It would have been a lot nicer to have it the July release because this > > > means that we'll have the released libvirt broken during almost the > > > whole rc phase of QEMU 3.0, but the release is planned for Aug 8th the > > > earliest, so I guess we're still okay. People using QEMU from git will > > > just need libvirt from git as well. > > > > Speaking as an innocent* bystander: > > > > I would usually presume that I can use any recent libvirt to test > > current QEMU, even bleeding edge. In this case, not even the latest > > released libvirt version will be fine, I would also need to build > > libvirt from git (which is probably not something a non-libvirt > > developer will usually do). If everything goes according to plan, I can > > only test QEMU with a released libvirt version at the very tail end of > > hardfreeze, where only release blockers are appropriate. > > I understand where you're coming from, but let's be honest: It's not as > if disk geometry or serial numbers were features that absolutely need > to be there to give QEMU any testing. Consider people running regression tests: They likely have a set of machine definitions they use, some of which may include serial numbers et al., and that suddenly breaks if they try with a newer QEMU. If they can just update to a newer (released) libvirt, their regression tests continue to work. > > Also, my understanding has always been that we expect users to have a > libvirt version that isn't older than QEMU. It would be useful to set a > clear policy for this and document it. My understanding has been that while a recent-ish libvirt might not exploit the latest QEMU features, it still continues to work. But yes, this is a good point. We need to agree on a clear policy and document that. > > > I think it would be really beneficial to general QEMU test coverage to > > push deleting this option back a release or two. We should make testing > > QEMU in conjunction with libvirt as uncomplicated as possible. > > Essentially, what is important to me isn't getting these options dropped > exactly in 3.0, but not setting a bad precedence that deprecation isn't > actually worth anything. We may easily end up with this deprecation > process: > > depreate a feature > release QEMU version n + 1 > release QEMU version n + 2 > remove the feature > while libvirt hasn't removed use of the feature: > # ...and why should it when everything is still working? > reinstate the feature > release QEMU version n + x > remove the feature > > When management tools know that this is the process, the motivation to > remove the use of the feature gets even lower (not out of malice, but > because there will be always more important things), so this will > "optimise" itself into an endless loop and we're back to never actually > removing old cruft that impedes development. I understand your concern, but not having a way out if something fell through the cracks is hurting people testing QEMU -- IOW, people we really don't want to hurt. Ideas on what could help: - A clearer way to communicate to libvirt users that libvirt is using a deprecated API, so that they can report it and libvirt can change its code. The main problem is that people usually don't read logs if everything seems to work fine... - A documented way in our QEMU deprecation process to hold off for one release, which can be used at most twice (or maybe just once?) No endless loops that way :) > > The libvirt patch has just been merged (and I'm almost sure that this > wouldn't have happened so quickly if I had just reverted the patch right > away), so at least we know now that this specific instance of the loop > is going to terminate. > > What's left is first and foremost that we need to sort out our broken > deprecation mechanism, and if that gets done, I don't mind if someone > wants to revert the patch for 3.0 as long as they also take care that it > gets back into 3.1. Fully agreed on sorting out our deprecation mechanism. I can send a revert patch, if nobody else beats me to it. Thanks! -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
