Open Stack

On 11/01/2012 08:28 AM, Mark McLoughlin wrote:
> On Wed, 2012-10-31 at 12:57 +0000, Pádraig Brady wrote:
>> On 10/31/2012 12:08 PM, Gary Kotton wrote:
>>> Hi,
>>> Whilst back porting patches to the Quantum stable folsom branch I have encountered a very frustrating problem which I think that should be discussed. All of the stable quantum patches approved in the last few hours are failing unit tests. This seems to be due to one of the imported packages being problematic (the hunch at the moment is that this could be sqlalchemy). At the moment this is under investigation. I am wondering if when we create a stable branch, we should specifically set the pip-requires package numbers.
>>> Any thoughts?
>>> Thanks
>>> Gary
>>
>> This was discussed at the design summit, with notes kept here:
>> https://etherpad.openstack.org/process-dependency-management
>>
>> One of the action items from there is:
>>
>> * freeze 'sane' version (max major version?) range at release time
>>
>> So by recording the max version in the pip-requires,
>> it would mean that newer versions wouldn't be pulled
>> in, in the future, that might break stuff.
>> Also distros etc. should not be impacted since packages
>> manage dependencies independently.
> 
> Yep, I think we should go this route.
> 
> Basically, on master we should be testing the latest versions of
> libraries as they are released because the next release needs to work on
> distros with the very latest libraries.
> 
> On the stable branch, I think we mostly just want to keep the gate
> working and not be randomly impacted by new libraries.
> 
> The question is how to do this. The Jenkins gate job runs 'pip freeze'
> so we have a source of this info:
> 
>   http://logs.openstack.org/13829/1/gate/gate-quantum-python27/1696/console.html.gz
> 
> and since that's the commit which started the stable/folsom branch, it
> should be the list we want.
> 
> So we can take that 'pip freeze' output and use it to update the
> pip-requires. I've re-purposed a script Monty wrote for this:
> 
>   https://gist.github.com/3992317
> 
> and the result looks like this:
> 
>   https://review.openstack.org/15186
> 
> Thoughts?

I think the general approach is great - but I think that doing an
absolute == has the potential to break current releases on older distro
versions. Instead, if we add a ,<=current_version to the end of the
version string, then we protect ourselves from new unexpected pypi
releases without asserting a new lower-bound on acceptable older library
releases which may or may not be a valid assertion.

Monty