On 07/30/2014 03:34 PM, Clark Boylan 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 :)
).
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.
We, as a project, MUST be able to push forward to new versions of
software. libvirt is 100% backportable without screwing precise, so it
totally fits well within the scope of our current policy.
If there are additional hardships this causes devs, then we should
investigate fixing them rather than avoiding upgrading because the
_previous_ ubuntu LTS doesn't happen to have a new enough library.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
