Re: [Openstack-operators] [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release
On Mon, Apr 09, 2018 at 04:24:06PM -0500, Matt Riedemann wrote:
> On 4/9/2018 4:58 AM, Kashyap Chamarthy wrote:
> > Keep in mind that Matt has a tendency to sometimes unfairly
> > over-simplify others views;-). More seriously, c'mon Matt; I went out
> > of my way to spend time learning about Debian's packaging structure and
> > trying to get the details right by talking to folks on
> > #debian-backports. And as you may have seen, I marked the patch[*] as
> > "RFC", and repeatedly said that I'm working on an agreeable lowest
> > common denominator.
>
> Sorry Kashyap, I didn't mean to offend. I was hoping "delicious bugs" would
> have made that obvious but I can see how it's not. You've done a great,
> thorough job on sorting this all out.
No problem at all. I know your communication style enough to not take
offence :-). Thanks for the words!
> Since I didn't know what "RFC" meant until googling it today, how about
> dropping that from the patch so I can +2 it?
Sure, I meant to remove it on my last iteration; now dropped it. (As
you noted on the review, should've used '-Workflow', but I typed "RFC"
out of muscle memory.)
Thanks for the review.
* * *
Aside: On the other patch[+] that actually bumps for "Rocky" and fixes
the resulting unit test fallout, I intend to fix the rest of the failing
tests sometime this week. Remaining tests to be fixed:
test_live_migration_update_serial_console_xml
test_live_migration_with_valid_target_connect_addr
test_live_migration_raises_exception
test_virtuozzo_min_version_ok
test_min_version_ppc_ok
test_live_migration_update_graphics_xml
test_min_version_s390_ok
[+] https://review.openstack.org/#/c/558783/ -- libvirt: Bump
MIN_{LIBVIRT,QEMU}_VERSION for "Rocky"
--
/kashyap
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release
On 4/9/2018 4:58 AM, Kashyap Chamarthy wrote: Keep in mind that Matt has a tendency to sometimes unfairly over-simplify others views;-). More seriously, c'mon Matt; I went out of my way to spend time learning about Debian's packaging structure and trying to get the details right by talking to folks on #debian-backports. And as you may have seen, I marked the patch[*] as "RFC", and repeatedly said that I'm working on an agreeable lowest common denominator. Sorry Kashyap, I didn't mean to offend. I was hoping "delicious bugs" would have made that obvious but I can see how it's not. You've done a great, thorough job on sorting this all out. Since I didn't know what "RFC" meant until googling it today, how about dropping that from the patch so I can +2 it? -- Thanks, Matt ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release
On Fri, Apr 06, 2018 at 12:12:31PM -0500, Matt Riedemann wrote: > On 4/6/2018 12:07 PM, Kashyap Chamarthy wrote: > > FWIW, I'd suggest so, if it's not too much maintenance. It'll just > > spare you additional bug reports in that area, and the overall default > > experience when dealing with CPU models would be relatively much better. > > (Another way to look at it is, multiple other "conservative" long-term > > stable distributions also provide libvirt 3.2.0 and QEMU 2.9.0, so that > > should give you confidence.) > > > > Again, I don't want to push too hard on this. If that'll be messy from > > a package maintainance POV for you / Debian maintainers, then we could > > settle with whatever is in 'Stretch'. > > Keep in mind that Kashyap has a tendency to want the latest and greatest of > libvirt and qemu at all times for all of those delicious bug fixes. Keep in mind that Matt has a tendency to sometimes unfairly over-simplify others views ;-). More seriously, c'mon Matt; I went out of my way to spend time learning about Debian's packaging structure and trying to get the details right by talking to folks on #debian-backports. And as you may have seen, I marked the patch[*] as "RFC", and repeatedly said that I'm working on an agreeable lowest common denominator. > But we also know that new code also brings new not-yet-fixed bugs. Yep, of course. > Keep in mind the big picture here, we're talking about bumping from > minimum required (in Rocky) libvirt 1.3.1 to at least 3.0.0 (in Stein) > and qemu 2.5.0 to at least 2.8.0, so I think that's already covering > some good ground. Let's not get greedy. :) Sure :-) Also if there's a way we can avoid bugs in the default experience with minimal effort, we should. Anyway, there we go: changed the patch[*] to what's in Stretch. [*] https://review.openstack.org/#/c/558171/ -- /kashyap ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release
On 4/6/2018 12:07 PM, Kashyap Chamarthy wrote: FWIW, I'd suggest so, if it's not too much maintenance. It'll just spare you additional bug reports in that area, and the overall default experience when dealing with CPU models would be relatively much better. (Another way to look at it is, multiple other "conservative" long-term stable distributions also provide libvirt 3.2.0 and QEMU 2.9.0, so that should give you confidence.) Again, I don't want to push too hard on this. If that'll be messy from a package maintainance POV for you / Debian maintainers, then we could settle with whatever is in 'Stretch'. Keep in mind that Kashyap has a tendency to want the latest and greatest of libvirt and qemu at all times for all of those delicious bug fixes. But we also know that new code also brings new not-yet-fixed bugs. Keep in mind the big picture here, we're talking about bumping from minimum required (in Rocky) libvirt 1.3.1 to at least 3.0.0 (in Stein) and qemu 2.5.0 to at least 2.8.0, so I think that's already covering some good ground. Let's not get greedy. :) -- Thanks, Matt ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release
On Fri, Apr 06, 2018 at 06:07:18PM +0200, Thomas Goirand wrote: > On 04/06/2018 12:07 PM, Kashyap Chamarthy wrote: [...] > > Note: You don't even have to build the versions from 'Buster', which are > > quite new. Just the slightly more conservative libvirt 3.2.0 and QEMU > > 2.9.0 -- only if it's possbile. > > Actually, for *official* backports, it's the policy to always update to > wwhatever is in testing until testing is frozen. I see. Sure, that's fine, too (as "Queens" UCA also has it). Whatever is efficient and least painful from a maintenance POV. > I could maintain an unofficial backport in stretch-stein.debian.net > though. > > > That said ... I just spent comparing the release notes of libvirt 3.0.0 > > and libvirt 3.2.0[1][2]. By using libvirt 3.2.0 and QEMU 2.9.0, Debian > > users > > will be spared from a lot of critical bugs (see all the list in [3]) in > > CPU comparision area. > > > > [1] > > https://www.redhat.com/archives/libvirt-announce/2017-April/msg0.html > > -- Release of libvirt-3.2.0 > > [2] > > https://www.redhat.com/archives/libvirt-announce/2017-January/msg3.html > > -- Release of libvirt-3.0.0 > > [3] https://www.redhat.com/archives/libvir-list/2017-February/msg01295.html > > So, because of these bugs, would you already advise Nova users to use > libvirt 3.2.0 for Queens? FWIW, I'd suggest so, if it's not too much maintenance. It'll just spare you additional bug reports in that area, and the overall default experience when dealing with CPU models would be relatively much better. (Another way to look at it is, multiple other "conservative" long-term stable distributions also provide libvirt 3.2.0 and QEMU 2.9.0, so that should give you confidence.) Again, I don't want to push too hard on this. If that'll be messy from a package maintainance POV for you / Debian maintainers, then we could settle with whatever is in 'Stretch'. Thanks for looking into it. -- /kashyap ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release
On Thu, Apr 05, 2018 at 06:11:26PM -0500, Matt Riedemann wrote: > On 4/5/2018 3:32 PM, Thomas Goirand wrote: > > If you don't absolutely need new features from libvirt 3.2.0 and 3.0.0 > > is fine, please choose 3.0.0 as minimum. > > > > If you don't absolutely need new features from qemu 2.9.0 and 2.8.0 is > > fine, please choose 2.8.0 as minimum. > > > > If you don't absolutely need new features from libguestfs 1.36 and 1.34 > > is fine, please choose 1.34 as minimum. > > New features in the libvirt driver which depend on minimum versions of > libvirt/qemu/libguestfs (or arch for that matter) are always conditional, so > I think it's reasonable to go with the lower bound for Debian. We can still > support the features for the newer versions if you're running a system with > those versions, but not penalize people with slightly older versions if not. Yep, we can trivially set the lower bound to versions in 'Stretch'. The intention was never to "penalize" distributions w/ older versions. I was just checking if Debian 'Stretch' users can be spared from the myriad of CPU-modelling related issues (see my other reply for specifics) that are all fixed with 3.2.0 (and QMEU 2.9.0) by default -- without spending inordinate amounts of time and messy backporting procedures. Since rest of all the other stable distributions are using it. I'll wait a day to hear from Zigo, then I'll just rewrite the patch[*] to use what's currently in 'Stretch'. [*] https://review.openstack.org/#/c/558171/ -- /kashyap ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release
On Thu, Apr 05, 2018 at 10:32:13PM +0200, Thomas Goirand wrote: Hey Zigo, thanks for the detailed response; a couple of comments below. [...] > backport of libvirt/QEMU/libguestfs more in details > --- > > I already attempted the backports from Debian Buster to Stretch. > > All of the 3 components (libvirt, qemu & libguestfs) could be built > without extra dependency, which is a very good thing. > > - libvirt 4.1.0 compiled without issue, though the dh_install phase > failed with this error: > > dh_install: Cannot find (any matches for) "/usr/lib/*/wireshark/" (tried > in "." and "debian/tmp") > dh_install: libvirt-wireshark missing files: /usr/lib/*/wireshark/ > dh_install: missing files, aborting That seems like a problem in the Debian packaging system, not in libvirt. I double-checked with the upstream folks, and the install rules for Wireshark plugin doesn't have /*/ in there. > - qemu 2.11 built perfectly with zero change. > > - libguestfs 1.36.13 only needed to have fdisk replaced by util-linux as > build-depends (fdisk is now a separate package in Buster). Great. Note: You don't even have to build the versions from 'Buster', which are quite new. Just the slightly more conservative libvirt 3.2.0 and QEMU 2.9.0 -- only if it's possbile. [...] > Conclusion: > --- > > If you don't absolutely need new features from libvirt 3.2.0 and 3.0.0 > is fine, please choose 3.0.0 as minimum. > > If you don't absolutely need new features from qemu 2.9.0 and 2.8.0 is > fine, please choose 2.8.0 as minimum. > > If you don't absolutely need new features from libguestfs 1.36 and 1.34 > is fine, please choose 1.34 as minimum. > > If you do need these new features, I'll do my best adapt. :) Sure, can use the 3.0.0 (& QEMU 2.8.0), instead of 3.2.0, as we don't want to "penalize" (that was never the intention) distros with slightly older versions. That said ... I just spent comparing the release notes of libvirt 3.0.0 and libvirt 3.2.0[1][2]. By using libvirt 3.2.0 and QEMU 2.9.0, Debian users will be spared from a lot of critical bugs (see all the list in [3]) in CPU comparision area. [1] https://www.redhat.com/archives/libvirt-announce/2017-April/msg0.html -- Release of libvirt-3.2.0 [2] https://www.redhat.com/archives/libvirt-announce/2017-January/msg3.html -- Release of libvirt-3.0.0 [3] https://www.redhat.com/archives/libvir-list/2017-February/msg01295.html [...] -- /kashyap ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release
On 4/5/2018 3:32 PM, Thomas Goirand wrote: If you don't absolutely need new features from libvirt 3.2.0 and 3.0.0 is fine, please choose 3.0.0 as minimum. If you don't absolutely need new features from qemu 2.9.0 and 2.8.0 is fine, please choose 2.8.0 as minimum. If you don't absolutely need new features from libguestfs 1.36 and 1.34 is fine, please choose 1.34 as minimum. New features in the libvirt driver which depend on minimum versions of libvirt/qemu/libguestfs (or arch for that matter) are always conditional, so I think it's reasonable to go with the lower bound for Debian. We can still support the features for the newer versions if you're running a system with those versions, but not penalize people with slightly older versions if not. -- Thanks, Matt ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release
On 04/04/2018 10:45 AM, Kashyap Chamarthy wrote: > Answering my own questions about Debian -- > > From looking at the Debian Archive[1][2], these are the versions for > 'Stretch' (the current stable release) and in the upcoming 'Buster' > release: > > libvirt | 3.0.0-4+deb9u2 | stretch > libvirt | 4.1.0-2| buster > > qemu| 1:2.8+dfsg-6+deb9u3| stretch > qemu| 1:2.11+dfsg-1 | buster > > I also talked on #debian-backports IRC channel on OFTC network, where I > asked: > > "What I'm essentially looking for is: "How can 'stretch' users get > libvirt 3.2.0 and QEMU 2.9.0, even if via a different repository. > As they are proposed to be least common denominator versions across > distributions." > > And two people said: Then the versions from 'Buster' could be backported > to 'stretch-backports'. The process for that is to: "ask the maintainer > of those package and Cc to the backports mailing list." > > Any takers? > > [0] https://packages.debian.org/stretch-backports/ > [1] https://qa.debian.org/madison.php?package=libvirt > [2] https://qa.debian.org/madison.php?package=qemu Hi Kashyap, Thanks for your considering of Debian, asking me and giving enough time for answering! Here's my thoughts. I updated the wiki page as you suggested [1]. As i wrote on IRC, we don't need to care about Jessie, so I removed Jessie, and added Buster/SID. tl;dr: just skip this section & go to conclusion backport of libvirt/QEMU/libguestfs more in details --- I already attempted the backports from Debian Buster to Stretch. All of the 3 components (libvirt, qemu & libguestfs) could be built without extra dependency, which is a very good thing. - libvirt 4.1.0 compiled without issue, though the dh_install phase failed with this error: dh_install: Cannot find (any matches for) "/usr/lib/*/wireshark/" (tried in "." and "debian/tmp") dh_install: libvirt-wireshark missing files: /usr/lib/*/wireshark/ dh_install: missing files, aborting Without more investigation but this build log, it's likely a minor fix in debian/*.install files to make it possible to backport the package. - qemu 2.11 built perfectly with zero change. - libguestfs 1.36.13 only needed to have fdisk replaced by util-linux as build-depends (fdisk is now a separate package in Buster). So it looks like easy to backport these 3 *AT THIS TIME*. [2] However, without a cristal ball, nobody can tell how hard it will be to backport these *IN A YEAR FROM NOW*. Conclusion: --- If you don't absolutely need new features from libvirt 3.2.0 and 3.0.0 is fine, please choose 3.0.0 as minimum. If you don't absolutely need new features from qemu 2.9.0 and 2.8.0 is fine, please choose 2.8.0 as minimum. If you don't absolutely need new features from libguestfs 1.36 and 1.34 is fine, please choose 1.34 as minimum. If you do need these new features, I'll do my best adapt. :) About Buster freeze & OpenStack Stein backports to Debian Stretch - Now, about Buster. As you know, Debian doesn't have planned release dates. Though here's the stats showing that roughly, there's a new Debian every 2 years, and the freeze takes about 6 months. https://wiki.debian.org/DebianReleases#Release_statistics With this logic and considering Stretch was released last year in June, after Stein is released, Buster will probably start its freeze. If the Debian freeze happens later, good for me, I'll have more time to make Stein better. But then Debian users will probably expect an OpenStack Stein backport to Debian Stretch, and that's where it can become tricky to backport these 3 packages. The end --- I hope the above isn't too long, and helps to take the best decision, Cheers, Thomas Goirand (zigo) [1] https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix#Distro_minimum_versions [2] I'm not shouting, just highlighting the important part! :) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release
On Sat, Mar 31, 2018 at 04:09:29PM +0200, Kashyap Chamarthy wrote: > [Meta comment: corrected the email subject: "Solar" --> "Stein"] Here's a change to get the discussion rolling: https://review.openstack.org/#/c/558171/ -- [RFC] Pick next minimum libvirt / QEMU versions for "Stein" > On Fri, Mar 30, 2018 at 04:26:43PM +0200, Kashyap Chamarthy wrote: [...] > > Taking the DistroSupportMatrix into picture, for the sake of discussion, > > how about the following NEXT_MIN versions for "Solar" release: > > > > > > (a) libvirt: 3.2.0 (released on 23-Feb-2017) > > > > This satisfies most distributions, but will affect Debian "Stretch", > > > > as they only have 3.0.0 in the stable branch -- I've checked their > > repositories[3][4]. Although the latest update for the stable > > release "Stretch (9.4)" was released only on 10-March-2018, I don't > > think they increment libvirt and QEMU versions in stable. Is > > there another way for "Stretch (9.4)" users to get the relevant > > versions from elsewhere? I learn that there's Debian 'stretch-backports'[0], which might provide (but doesn't yet) a newer stable version. > > (b) QEMU: 2.9.0 (released on 20-Apr-2017) > > > > This too satisfies most distributions but will affect Oracle Linux > > -- which seem to ship QEMU 1.5.3 (released in August 2013) with > > their "7", from the Wiki. And will also affect Debian "Stretch" -- > > as it only has 2.8.0 > > > > Can folks chime in here? Answering my own questions about Debian -- From looking at the Debian Archive[1][2], these are the versions for 'Stretch' (the current stable release) and in the upcoming 'Buster' release: libvirt | 3.0.0-4+deb9u2 | stretch libvirt | 4.1.0-2| buster qemu| 1:2.8+dfsg-6+deb9u3| stretch qemu| 1:2.11+dfsg-1 | buster I also talked on #debian-backports IRC channel on OFTC network, where I asked: "What I'm essentially looking for is: "How can 'stretch' users get libvirt 3.2.0 and QEMU 2.9.0, even if via a different repository. As they are proposed to be least common denominator versions across distributions." And two people said: Then the versions from 'Buster' could be backported to 'stretch-backports'. The process for that is to: "ask the maintainer of those package and Cc to the backports mailing list." Any takers? [0] https://packages.debian.org/stretch-backports/ [1] https://qa.debian.org/madison.php?package=libvirt [2] https://qa.debian.org/madison.php?package=qemu -- /kashyap ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
