8:58 a.m.
On Wed, 4 Jul 2018 15:34:40 +0200
Kevin Wolf <kwolf(a)redhat.com> wrote:
Am 04.07.2018 um 15:02 hat Cornelia Huck geschrieben:
> On Tue, 3 Jul 2018 13:32:29 +0200
> Kevin Wolf <kwolf(a)redhat.com> 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 "[libvirt] [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!