Open Stack

On 15 May 2015 at 11:51, Daniel P. Berrange <berrange at 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 because that is a layer above that does not directly impact on
> the hardware or their base platform certification.

Sadly, this is the reality at the moment.

> I could see us increase libvirt to 0.10.2 and qemu to 0.12.1.2as, assuming
> opensuse 12.2 is end of life, then rhel-6 is the next oldest platform that
> is still supported. For that I would make liberty print a warning on start
> if libvirt was in the range 0.9.9 < 0.10.2, likewise for QEMU, and then
> change the min version in  Mxxxx.

Sounds good:
https://review.openstack.org/#/c/183220/

I feel we should add warnings for libvirt < 1.2.2 to say its untested.

Its tempting to say its scheduled for removal in N? So we have time to
work out if thats possible.

Thanks,
John