Re: [Openstack-operators] [nova] Can we bump MIN_LIBVIRT_VERSION to 1.2.2 in Liberty?
On Fri, May 15, 2015 at 06:14:08PM +0100, John Garbutt wrote: On 15 May 2015 at 17:41, Daniel P. Berrange berra...@redhat.com wrote: Its tempting to say its scheduled for removal in N? So we have time to work out if thats possible. I think that at the start of each dev cycle, we look at the distros we wish to target and identify if any can be dropped or have been EOLd. Then use that to decide what to deprecate in that cycle, for deletion in the next cycle. Trying to second guess too many cycles in advance is probably counter-productive. Well, as you mentioned, its not just about EOLed right? Its more about adoption curves vs maintenance costs? Yes, true. For short lived distros (eg Fedora/Ubuntu like 12-18 month lifetime) then its about EOL dates.. For long lived distros (RHEL, and other enterprise distros) then it is more about adoption curve and maintenance cost/phase. My idea was to start the conversation about when most folks are likely to move. They have already said no to deprecating in liberty, removal in M. I am curious if they still see themselves on RHEL 6.x in N? Maybe the answer is still yes? I guess its pretty hard to predict but IME users will always say no to killing their existing platform because why change anything if it isn't broken :-) So we probably do need to give them a little nudge at some point. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [nova] Can we bump MIN_LIBVIRT_VERSION to 1.2.2 in Liberty?
I'd imagine the use of a Software Collection that includes a newer python for the OpenStack packages, or RHOSP, being purpose built for OpenStack, will take the plunge and upgrade the system python version. - jlk On Fri, May 15, 2015 at 6:46 PM, Tim Bell tim.b...@cern.ch wrote: I¹m not seeing an easy solution other than to migrate to v7 in the longer termŠ we¹ve worked with RDO to get the packages back ported for Juno for v6 but with python pre-reqs this is going to get more and more difficult. It is one of those regular scenarios we encounter where neither staying still or moving forward are particularly attractive. It makes me wonder how RHOSP will be supporting these environments (or is the commitment to keep an OpenStack release working for a period of time rather than guaranteeing that you do not need to upgrade the OS ?)Š Tim On 5/15/15, 12:04 PM, Daniel P. Berrange berra...@redhat.com wrote: On Fri, May 15, 2015 at 06:25:48AM +, Tim Bell wrote: What are the benefits of upping the minimum libvirt ? We've got 3,200 hypervisors still running v6 with a plan to gradually migrate to 7 but this does take some time. We'll see with RDO this week as to how/if we can get something going with SCL on v6. Tim, if you can't get Python 2.7 from SCL working acceptably, what would be your fallback approach ? Would you try to patch Nova to work on Python 2.6 again, or would you simply delay updating Nova until you have v7 hosts to run on ? Likewise if we were to decide to drop support for libvrt in v6 from Nova, how would you imagine dealing with that ? Would you just re-add the compat code we removed from Nova to make it work with old libvirt again ? Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [nova] Can we bump MIN_LIBVIRT_VERSION to 1.2.2 in Liberty?
What are the benefits of upping the minimum libvirt ? We've got 3,200 hypervisors still running v6 with a plan to gradually migrate to 7 but this does take some time. We'll see with RDO this week as to how/if we can get something going with SCL on v6. Tim -Original Message- From: Kris G. Lindgren [mailto:klindg...@godaddy.com] Sent: 14 May 2015 21:59 To: Matt Riedemann; openstack-operators@lists.openstack.org Subject: Re: [Openstack-operators] [nova] Can we bump MIN_LIBVIRT_VERSION to 1.2.2 in Liberty? How would this impact someone running juno nova-compute on rhel 6 boxes? Or installing the python2.7 from SCL and running kilo+ code on rhel6? For [3] it couldn't we get the exact same information from /proc/cpuinfo? Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. On 5/14/15, 1:23 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: The minimum required version of libvirt in the driver is 0.9.11 still [1]. We've been gating against 1.2.2 in Ubuntu Trusty 14.04 since Juno. The libvirt distro support matrix is here: [2] Can we safely assume the people aren't going to be running Libvirt compute nodes on RHEL 7.1 or Ubuntu Precise? Regarding RHEL, I think this is a safe bet because in Kilo nova dropped python 2.6 support and RHEL 6 doesn't have py26 so you'd be in trouble running kilo+ nova on RHEL 6.x anyway. There are some workarounds in the code [3] I'd like to see removed by bumping the minimum required version. [1] http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/libvirt/dri ver .py?id=2015.1.0#n335 [2] https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix [3] http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/libvirt/hos t.p y?id=2015.1.0#n754 -- Thanks, Matt Riedemann ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [nova] Can we bump MIN_LIBVIRT_VERSION to 1.2.2 in Liberty?
On Fri, May 15, 2015 at 06:25:48AM +, Tim Bell wrote: What are the benefits of upping the minimum libvirt ? We've got 3,200 hypervisors still running v6 with a plan to gradually migrate to 7 but this does take some time. We'll see with RDO this week as to how/if we can get something going with SCL on v6. Tim, if you can't get Python 2.7 from SCL working acceptably, what would be your fallback approach ? Would you try to patch Nova to work on Python 2.6 again, or would you simply delay updating Nova until you have v7 hosts to run on ? Likewise if we were to decide to drop support for libvrt in v6 from Nova, how would you imagine dealing with that ? Would you just re-add the compat code we removed from Nova to make it work with old libvirt again ? Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [nova] Can we bump MIN_LIBVIRT_VERSION to 1.2.2 in Liberty?
On Fri, May 15, 2015 at 11:51:22AM +0100, Daniel P. Berrange wrote: On Thu, May 14, 2015 at 02:23:25PM -0500, Matt Riedemann wrote: The minimum required version of libvirt in the driver is 0.9.11 still [1]. We've been gating against 1.2.2 in Ubuntu Trusty 14.04 since Juno. The libvirt distro support matrix is here: [2] Can we safely assume the people aren't going to be running Libvirt compute nodes on RHEL 7.1 or Ubuntu Precise? I don't really think so - at the very least Fedora 20 and RHEL 7.0 are still actively supported platforms by their vendors, which both have older libvirt versions (1.1.3 and 1.1.1 respectively). I'm not sure whether SUSE team consider any of the 12.x versions to still be actively supported platforms or not, likewise which 13.x versions are under active support. Regarding RHEL, I think this is a safe bet because in Kilo nova dropped python 2.6 support and RHEL 6 doesn't have py26 so you'd be in trouble running kilo+ nova on RHEL 6.x anyway. There are add-on repos for RHEL-6 and RHEL-7 that provide newer python versions so (py27, various py3x), so it is not unreasonable for people to consider sticking with RHEL-6 if that is what their existing deployment is based on. Certainly new deployments though I'd expect to be RHEL-7 based. There are some workarounds in the code [3] I'd like to see removed by bumping the minimum required version. Sure, its nice to remove workarounds from a cleanliness POV, but I'm generally pretty conservative about doing so, because in the majority of case (while it looks ugly) it is not really a significant burden on maintainers to keep it around. This example is really just that. It certainly looks ugly, but we have the code there now, it is doing the job for people who have that problem and it isn't really having any measurable impact on our ability to maintain the libvirt code. Removing this code won't lessen our maintainance burden in any way, but it will unquestionably impact our users by removing support for the platform they may be currently deployed on. BTW, the code you quote here: http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/libvirt/host.py?id=2015.1.0#n754 is not actually working around a bug the libvirt hypervisor. It is in fact a bug in the libvirt-python API binding. As such we don't actually need to increase the min required libvirt to be able to remove that check. In fact increasing the min required libvirt is the wrong thing todo, because it is possible for someone to have the min required libvirt, but by accessing it via an older libvirt-python which still has the bug. So what's really needed is a dep on libvirt-python = 1.2.0, not libvirt. We don't express min required versions for libvirt-python in the requirements.txt file though, since it is an optional package and we don't have any mechanism for recording min versions for those AFAIK. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [nova] Can we bump MIN_LIBVIRT_VERSION to 1.2.2 in Liberty?
On Fri, May 15, 2015 at 05:27:35PM +0100, John Garbutt wrote: On 15 May 2015 at 11:51, Daniel P. Berrange berra...@redhat.com wrote: On Thu, May 14, 2015 at 02:23:25PM -0500, Matt Riedemann wrote: The minimum required version of libvirt in the driver is 0.9.11 still [1]. We've been gating against 1.2.2 in Ubuntu Trusty 14.04 since Juno. The libvirt distro support matrix is here: [2] Can we safely assume the people aren't going to be running Libvirt compute nodes on RHEL 7.1 or Ubuntu Precise? I don't really think so - at the very least Fedora 20 and RHEL 7.0 are still actively supported platforms by their vendors, which both have older libvirt versions (1.1.3 and 1.1.1 respectively). I'm not sure whether SUSE team consider any of the 12.x versions to still be actively supported platforms or not, likewise which 13.x versions are under active support. As I understand it, RHEL 5.0 is supported until March 31, 2017. https://access.redhat.com/support/policy/updates/errata Where should we draw the line? Its a tricky question. No one is seriously deploying KVM on RHEL-5 any more though, nor has done for quite a while, as RHEL-5 was very immature for KVM. RHEL-6.x though is a solid platform for KVM that is still a widely deployed platform for virtualization, even for brand new deployments. The cut off line is difficult to set in stone - it takes a bit of analysis to understand what the real world popularity of the platform is.. Regarding RHEL, I think this is a safe bet because in Kilo nova dropped python 2.6 support and RHEL 6 doesn't have py26 so you'd be in trouble running kilo+ nova on RHEL 6.x anyway. There are add-on repos for RHEL-6 and RHEL-7 that provide newer python versions so (py27, various py3x), so it is not unreasonable for people to consider sticking with RHEL-6 if that is what their existing deployment is based on. Certainly new deployments though I'd expect to be RHEL-7 based. It seems like we are OK with deprecating support for libvirt 0.10.2 in M then? Yep. In this case, I just don't see compelling benefits to Nova libvirt maint to justify increasing the minimum version to the level you suggest, and it has a clear negative impact on our users which they will not be able to easily deal with. They will be left with 3 options all of which are unsatisfactory - Upgrade from RHEL-6 to RHEL-7 - a major undertaking for most organizations - Upgrade libvirt on RHEL-6 - they essentially take on the support burden for the hypervisor themselves, loosing support from the vendor - Re-add the code we remove from Nova - we've given users a maint burden, to rid ourselves of code that was posing no real maint burden on ourselves. Thats assuming vendors do not backport libvirt and QEMU and support that. In early updates we do rebase to newer libvirt QEMU in RHEL, but RHEL-6 has past the point in its lifecycle where we do that, so the versions are effectively fixed now for remainder of RHEL-6.x. As a more general point, I think we are lacking clear guidance on our policies around hypervisor platform support and thus have difficulty in deciding when it is reasonable for us to drop support for platforms. +1 Lets try to fixing this in Liberty. I see this as part of feature classification: http://libertydesignsummit.sched.org/event/7ee9be7e3b005880706a914f44b296ed Honestly, I want us to call out the exact combinations we test. But that in logs, or in the release notes , or docs, or some combination of all of those. Partly so we are honest about what we know works, partly so folks setup up and help us test more combinations users care about. This should really be true for everything, VMware, XenServer, Hyper-V and others. Yes indeed. We need to give our users keep information about what is tested, so that they can undertake their own testing (with tempest or equiv) when they deploy on platforms that don't 100% match what upstream tested, or can at least ask their vendors to confirm they have tested on their behalf. The hypervisor platform is very different. While OpenStack does achieve some level of testing coverage of the hypervisor platform version used in the gate, this testing is inconsequential compared to the level of testing that vendors put into their hypervisor platforms. That depends on the scope right... Sure, we don't really test the data plane, that is left the hypervisor vendor. But we do heavily test the control plane, and thats useful. I can't speak for other vendors, but when we test virtualization in RHEL, we specifically test the combination of libvirt + QEMU + kernel, so changing any part of that invalidates testing and certification to some degrees. There are also sometimes fixes to libvirt's RHEL code to deal with RHEL specific problems, so if deploying a new upstream libvirt users would loose some of those workarounds. Even if users
Re: [Openstack-operators] [nova] Can we bump MIN_LIBVIRT_VERSION to 1.2.2 in Liberty?
On 15 May 2015 at 11:51, Daniel P. Berrange berra...@redhat.com wrote: On Thu, May 14, 2015 at 02:23:25PM -0500, Matt Riedemann wrote: The minimum required version of libvirt in the driver is 0.9.11 still [1]. We've been gating against 1.2.2 in Ubuntu Trusty 14.04 since Juno. The libvirt distro support matrix is here: [2] Can we safely assume the people aren't going to be running Libvirt compute nodes on RHEL 7.1 or Ubuntu Precise? I don't really think so - at the very least Fedora 20 and RHEL 7.0 are still actively supported platforms by their vendors, which both have older libvirt versions (1.1.3 and 1.1.1 respectively). I'm not sure whether SUSE team consider any of the 12.x versions to still be actively supported platforms or not, likewise which 13.x versions are under active support. As I understand it, RHEL 5.0 is supported until March 31, 2017. https://access.redhat.com/support/policy/updates/errata Where should we draw the line? Its a tricky question. Regarding RHEL, I think this is a safe bet because in Kilo nova dropped python 2.6 support and RHEL 6 doesn't have py26 so you'd be in trouble running kilo+ nova on RHEL 6.x anyway. There are add-on repos for RHEL-6 and RHEL-7 that provide newer python versions so (py27, various py3x), so it is not unreasonable for people to consider sticking with RHEL-6 if that is what their existing deployment is based on. Certainly new deployments though I'd expect to be RHEL-7 based. It seems like we are OK with deprecating support for libvirt 0.10.2 in M then? There are some workarounds in the code [3] I'd like to see removed by bumping the minimum required version. Sure, its nice to remove workarounds from a cleanliness POV, but I'm generally pretty conservative about doing so, because in the majority of case (while it looks ugly) it is not really a significant burden on maintainers to keep it around. snip In this case, I just don't see compelling benefits to Nova libvirt maint to justify increasing the minimum version to the level you suggest, and it has a clear negative impact on our users which they will not be able to easily deal with. They will be left with 3 options all of which are unsatisfactory - Upgrade from RHEL-6 to RHEL-7 - a major undertaking for most organizations - Upgrade libvirt on RHEL-6 - they essentially take on the support burden for the hypervisor themselves, loosing support from the vendor - Re-add the code we remove from Nova - we've given users a maint burden, to rid ourselves of code that was posing no real maint burden on ourselves. Thats assuming vendors do not backport libvirt and QEMU and support that. As a more general point, I think we are lacking clear guidance on our policies around hypervisor platform support and thus have difficulty in deciding when it is reasonable for us to drop support for platforms. +1 Lets try to fixing this in Liberty. I see this as part of feature classification: http://libertydesignsummit.sched.org/event/7ee9be7e3b005880706a914f44b296ed Honestly, I want us to call out the exact combinations we test. But that in logs, or in the release notes , or docs, or some combination of all of those. Partly so we are honest about what we know works, partly so folks setup up and help us test more combinations users care about. This should really be true for everything, VMware, XenServer, Hyper-V and others. I think it is important to distinguish the hypervisor platform, from the openstack platform because there are different support implications there for users. Agreed. The hypervisor platform is very different. While OpenStack does achieve some level of testing coverage of the hypervisor platform version used in the gate, this testing is inconsequential compared to the level of testing that vendors put into their hypervisor platforms. That depends on the scope right... Sure, we don't really test the data plane, that is left the hypervisor vendor. But we do heavily test the control plane, and thats useful. Even if users decide they want to upgrade their hypervisor platform to a new version provided officially by the vendor, this is not always a quick or easy task. Many organizations have non-trivial internal testing and certification requirements before upgrading OS and/or hypervisor platforms. The hardware they own has to be certified as compatible and tested. They often have 3rd party monitoring and security auditing tools that need to be upgraded and integrated with the new platform. They may need todo long term stress tests to prove the new platform / hardare combination is reliable at meeting their uptime requirements, so on. So even with an active desire to upgrade their platform, it may take anywhere from 3-6 months to actually put that plan into pratice. It may seem strange, but at the same time they can be perfectly ok upgrading openstack in a matter of weeks, or even doing continuous deployment, simply
Re: [Openstack-operators] [nova] Can we bump MIN_LIBVIRT_VERSION to 1.2.2 in Liberty?
On 15 May 2015 at 17:41, Daniel P. Berrange berra...@redhat.com wrote: On Fri, May 15, 2015 at 05:27:35PM +0100, John Garbutt wrote: On 15 May 2015 at 11:51, Daniel P. Berrange berra...@redhat.com wrote: On Thu, May 14, 2015 at 02:23:25PM -0500, Matt Riedemann wrote: The minimum required version of libvirt in the driver is 0.9.11 still [1]. We've been gating against 1.2.2 in Ubuntu Trusty 14.04 since Juno. The libvirt distro support matrix is here: [2] Can we safely assume the people aren't going to be running Libvirt compute nodes on RHEL 7.1 or Ubuntu Precise? I don't really think so - at the very least Fedora 20 and RHEL 7.0 are still actively supported platforms by their vendors, which both have older libvirt versions (1.1.3 and 1.1.1 respectively). I'm not sure whether SUSE team consider any of the 12.x versions to still be actively supported platforms or not, likewise which 13.x versions are under active support. As I understand it, RHEL 5.0 is supported until March 31, 2017. https://access.redhat.com/support/policy/updates/errata Where should we draw the line? Its a tricky question. No one is seriously deploying KVM on RHEL-5 any more though, nor has done for quite a while, as RHEL-5 was very immature for KVM. RHEL-6.x though is a solid platform for KVM that is still a widely deployed platform for virtualization, even for brand new deployments. The cut off line is difficult to set in stone - it takes a bit of analysis to understand what the real world popularity of the platform is.. Yeah, makes sense. In this case, I just don't see compelling benefits to Nova libvirt maint to justify increasing the minimum version to the level you suggest, and it has a clear negative impact on our users which they will not be able to easily deal with. They will be left with 3 options all of which are unsatisfactory - Upgrade from RHEL-6 to RHEL-7 - a major undertaking for most organizations - Upgrade libvirt on RHEL-6 - they essentially take on the support burden for the hypervisor themselves, loosing support from the vendor - Re-add the code we remove from Nova - we've given users a maint burden, to rid ourselves of code that was posing no real maint burden on ourselves. Thats assuming vendors do not backport libvirt and QEMU and support that. In early updates we do rebase to newer libvirt QEMU in RHEL, but RHEL-6 has past the point in its lifecycle where we do that, so the versions are effectively fixed now for remainder of RHEL-6.x. Ah, OK. It seems I also slightly miss-read the options, you covered it there. As a more general point, I think we are lacking clear guidance on our policies around hypervisor platform support and thus have difficulty in deciding when it is reasonable for us to drop support for platforms. +1 Lets try to fixing this in Liberty. I see this as part of feature classification: http://libertydesignsummit.sched.org/event/7ee9be7e3b005880706a914f44b296ed Honestly, I want us to call out the exact combinations we test. But that in logs, or in the release notes , or docs, or some combination of all of those. Partly so we are honest about what we know works, partly so folks setup up and help us test more combinations users care about. This should really be true for everything, VMware, XenServer, Hyper-V and others. Yes indeed. We need to give our users keep information about what is tested, so that they can undertake their own testing (with tempest or equiv) when they deploy on platforms that don't 100% match what upstream tested, or can at least ask their vendors to confirm they have tested on their behalf. Cool, we agree there. The hypervisor platform is very different. While OpenStack does achieve some level of testing coverage of the hypervisor platform version used in the gate, this testing is inconsequential compared to the level of testing that vendors put into their hypervisor platforms. That depends on the scope right... Sure, we don't really test the data plane, that is left the hypervisor vendor. But we do heavily test the control plane, and thats useful. I can't speak for other vendors, but when we test virtualization in RHEL, we specifically test the combination of libvirt + QEMU + kernel, so changing any part of that invalidates testing and certification to some degrees. There are also sometimes fixes to libvirt's RHEL code to deal with RHEL specific problems, so if deploying a new upstream libvirt users would loose some of those workarounds. Agreed. I am just trying to be clear I don't expect OpenStack testing to test the hypervisor data plane. That feels like something the upstream projects or vendor, has to do themselves. Even if users decide they want to upgrade their hypervisor platform to a new version provided officially by the vendor, this is not always a quick or easy task. Many organizations have
Re: [Openstack-operators] [nova] Can we bump MIN_LIBVIRT_VERSION to 1.2.2 in Liberty?
On 5/14/2015 2:59 PM, Kris G. Lindgren wrote: How would this impact someone running juno nova-compute on rhel 6 boxes? Or installing the python2.7 from SCL and running kilo+ code on rhel6? For [3] it couldn't we get the exact same information from /proc/cpuinfo? Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. On 5/14/15, 1:23 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: The minimum required version of libvirt in the driver is 0.9.11 still [1]. We've been gating against 1.2.2 in Ubuntu Trusty 14.04 since Juno. The libvirt distro support matrix is here: [2] Can we safely assume the people aren't going to be running Libvirt compute nodes on RHEL 7.1 or Ubuntu Precise? Regarding RHEL, I think this is a safe bet because in Kilo nova dropped python 2.6 support and RHEL 6 doesn't have py26 so you'd be in trouble running kilo+ nova on RHEL 6.x anyway. There are some workarounds in the code [3] I'd like to see removed by bumping the minimum required version. [1] http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/libvirt/driver .py?id=2015.1.0#n335 [2] https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix [3] http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/libvirt/host.p y?id=2015.1.0#n754 -- Thanks, Matt Riedemann ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators This would be Liberty, so when you upgrade nova-compute to Liberty you'd also need to upgrade the host OS to something that supports libvirt = 1.2.2. -- Thanks, Matt Riedemann ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [nova] Can we bump MIN_LIBVIRT_VERSION to 1.2.2 in Liberty?
I'm +1 on this. If people want to run Liberty on an old platform, the onus is on them to figure out how to install the relevant deps on that platform. - jlk On Thu, May 14, 2015 at 2:33 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: On 5/14/2015 3:35 PM, Matt Riedemann wrote: On 5/14/2015 2:59 PM, Kris G. Lindgren wrote: How would this impact someone running juno nova-compute on rhel 6 boxes? Or installing the python2.7 from SCL and running kilo+ code on rhel6? For [3] it couldn't we get the exact same information from /proc/cpuinfo? Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. On 5/14/15, 1:23 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: The minimum required version of libvirt in the driver is 0.9.11 still [1]. We've been gating against 1.2.2 in Ubuntu Trusty 14.04 since Juno. The libvirt distro support matrix is here: [2] Can we safely assume the people aren't going to be running Libvirt compute nodes on RHEL 7.1 or Ubuntu Precise? Regarding RHEL, I think this is a safe bet because in Kilo nova dropped python 2.6 support and RHEL 6 doesn't have py26 so you'd be in trouble running kilo+ nova on RHEL 6.x anyway. There are some workarounds in the code [3] I'd like to see removed by bumping the minimum required version. [1] http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/libvirt/driver .py?id=2015.1.0#n335 [2] https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix [3] http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/libvirt/host.p y?id=2015.1.0#n754 -- Thanks, Matt Riedemann ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators This would be Liberty, so when you upgrade nova-compute to Liberty you'd also need to upgrade the host OS to something that supports libvirt = 1.2.2. Here is the patch to see what this would look like: https://review.openstack.org/#/c/183220/ -- Thanks, Matt Riedemann ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [nova] Can we bump MIN_LIBVIRT_VERSION to 1.2.2 in Liberty?
On 5/14/2015 3:35 PM, Matt Riedemann wrote: On 5/14/2015 2:59 PM, Kris G. Lindgren wrote: How would this impact someone running juno nova-compute on rhel 6 boxes? Or installing the python2.7 from SCL and running kilo+ code on rhel6? For [3] it couldn't we get the exact same information from /proc/cpuinfo? Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. On 5/14/15, 1:23 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: The minimum required version of libvirt in the driver is 0.9.11 still [1]. We've been gating against 1.2.2 in Ubuntu Trusty 14.04 since Juno. The libvirt distro support matrix is here: [2] Can we safely assume the people aren't going to be running Libvirt compute nodes on RHEL 7.1 or Ubuntu Precise? Regarding RHEL, I think this is a safe bet because in Kilo nova dropped python 2.6 support and RHEL 6 doesn't have py26 so you'd be in trouble running kilo+ nova on RHEL 6.x anyway. There are some workarounds in the code [3] I'd like to see removed by bumping the minimum required version. [1] http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/libvirt/driver .py?id=2015.1.0#n335 [2] https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix [3] http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/libvirt/host.p y?id=2015.1.0#n754 -- Thanks, Matt Riedemann ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators This would be Liberty, so when you upgrade nova-compute to Liberty you'd also need to upgrade the host OS to something that supports libvirt = 1.2.2. Here is the patch to see what this would look like: https://review.openstack.org/#/c/183220/ -- Thanks, Matt Riedemann ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
