On 8/5/2014 12:39 PM, Solly Ross wrote:
Just to add my two cents, while I get that people need to run on older versions
of software,
at a certain point you have to bump the minimum version. Even libvirt 0.9.11
is from April 3rd 2012.
That's two and a third years old at this point. I think at a certain point we need
to say "if you want
to run OpenStack on an older platform, then you'll need to run an older
OpenStack or backport the required
packages.
Best Regards,
Solly Ross
----- Original Message -----
From: "Joe Gordon" <joe.gord...@gmail.com>
To: "OpenStack Development Mailing List" <openstack-dev@lists.openstack.org>
Sent: Wednesday, July 30, 2014 7:07:13 PM
Subject: Re: [openstack-dev] [nova] so what do i do about libvirt-python if i'm
on precise?
On Jul 30, 2014 3:36 PM, "Clark Boylan" < cboy...@sapwetik.org > wrote:
On Wed, Jul 30, 2014, at 03:23 PM, Jeremy Stanley wrote:
On 2014-07-30 13:21:10 -0700 (-0700), Joe Gordon wrote:
While forcing people to move to a newer version of libvirt is
doable on most environments, do we want to do that now? What is
the benefit of doing so?
[...]
The only dog I have in this fight is that using the split-out
libvirt-python on PyPI means we finally get to run Nova unit tests
in virtualenvs which aren't built with system-site-packages enabled.
It's been a long-running headache which I'd like to see eradicated
everywhere we can. I understand though if we have to go about it
more slowly, I'm just excited to see it finally within our grasp.
--
Jeremy Stanley
We aren't quite forcing people to move to newer versions. Only those
installing nova test-requirements need newer libvirt. This does not
include people using eg devstack. I think it is reasonable to expect
people testing tip of nova master to have a reasonably newish test bed
to test it (its not like the Infra team moves at a really fast pace :)
).
Based on
http://lists.openstack.org/pipermail/openstack-dev/2014-July/041457.html
this patch is breaking people, which is the basis for my concerns. Perhaps
we should get some further details from Salvatore.
Avoiding system site packages in virtualenvs is a huge win particularly
for consistency of test results. It avoids pollution of site packages
that can happen differently across test machines. This particular type
of inconsistency has been the cause of the previously mentioned
headaches.
I agree this is a huge win, but I am just concerned we don't have any
deprecation cycle and just roll out a new requirement without a heads up.
Clark
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Yeah, I agree, I'm just, you know, a curmudgeon. I was doing a
stable/havana backport though on my ubuntu precise + libvirt 1.2.2 from
cloud-archive:icehouse and hit this bug:
https://bugs.launchpad.net/nova/+bug/1266711
I guess I should just get off my ass and setup a Trusty VM for Juno+
development and leave my Precise one alone for stable branch work.
--
Thanks,
Matt Riedemann
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
