Am 04.07.2018 um 15:43 hat Daniel P. Berrangé geschrieben: > On Wed, Jul 04, 2018 at 03:34:40PM +0200, Kevin Wolf wrote: > > 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. > > I'd venture to suggest disk geometry is almost never used in practice. > > serial strings, however, are pretty common, used by default in fact > by openstack. Interesting, good to know. > > 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 was actually mostly the opposite. We'll try not to > /knowingly/ break existing libvirt version if reasonable. We've not > always followed that, either by accident, or even intentionally in > some cases. What's never defined is just how old libvirt we care about > not breaking. Hm, that used to be true, yes. I still seem to remember that we've always expected a new libvirt version. Was that only about new features then? However, the deprecation policy essentially says that we will now knowingly break existing libvirt versions. With it, we also defined that we definitely don't care about libvirt versions older than QEMU n-2. You're right that we're not really making a statement for libvirt versions newer than that. > In the case of QEMU libvirt will in fact be fixed before QEMU 3.0 is > released, but only by a week or so. Probably two weeks because QEMU never does without the extra RC, but that doesn't make a big difference. > I think its mostly a case of being pragmatic about what we do in this > respect, rather than defining a hard rule. > > In this case I'd personally lean towards reverting this patch, since > merging it was not a critical blocker to other work that went into > 3.0 IIUC. So block maintaniers burden shouldn't be impacted by a > temporary revert and then re-merge when 3.1 opens. Having to remember to really bring it back to life after the release is a maintainer burden, which is one of the reasons why I don't want this "extended" deprecation process to become the norm. If it stays a one-time thing, and given that we're now in the freeze and a block-next branch will be active anyway, I'm okay with a temporary revert. > > > 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 > > Yeah, we definitely don't want to get into that kind of mess > in general. > > > 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. > > > > 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. > > What I think this really highlights is > > - Lack of libvirt paying attention to deprecations > - Lack of a way to get good diagnostic of violations when testing > > The first thing is just a human problem on libvirt side. > > The second thing could be addressed in code if there was an env variable > or cli option to turn all use of deprecated features into abort()s in > QEMU. That way libvirt automated testing against git master would have > a way to identify places where we use deprecated feature. The first one is basically just a result of the second. I think the most important improvement will be finding a way how to break things early for libvirt developers, but keep them working with a warning for everyone else. As a more short-term thing, is someone from libvirt looking at other present deprecations in QEMU and what needs to be done for them? Kevin -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
