Open Stack

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.