Open Stack

On 10/16/2015 7:16 AM, Sean Dague wrote:
> On 10/16/2015 04:23 AM, Thierry Carrez wrote:
>> Robert Collins wrote:
>>> [...]
>>> BUT: we haven't (ever!) tested that the lowest versions we specify
>>> work. When folk know they are adding a hard dependency on a version we
>>> do raise the lower versions, but thats adhoc and best effort today.
>>> I'd like to see a lower-constraints.txt reflecting the oldest version
>>> that works across all of OpenStack (as a good boundary case to test) -
>>> but we need to fix pip first to teach it to choose lower versions over
>>> higher versions (https://github.com/pypa/pip/issues/3188 - I thought
>>> I'd filed it previously but couldn't find it...)
>>>
>>> More generally, we don't [yet] have the testing setup to test multiple
>>> versions on an ongoing basis, so we can't actually make any statement
>>> other than 'upper-constraints.txt is known to work'. Note: before
>>> constraints we couldn't even make *that* statement. The statement we
>>> could make then was 'if you look up the change in gerrit and from that
>>> the CI dvsm test run which got through the gate, then you can
>>> figureout *a* version of the dependencies that worked.
>>
>> And that is the critical bit. The system we had in kilo and before may
>> appear to be more practical to interpret downstream, but the assertions
>> it was making were mostly untested. So the capping was a convenient
>> illusion: things beyond the cap may be working, and things below the cap
>> could actually be broken. At least the upper-constraints expresses
>> clearly the combination that works and was tested. Combined with the
>> uncapped requirements (which express what *should* be working, to the
>> best of our knowledge), they make a more accurate, albeit admittedly
>> more complex, set of information for downstream packagers.
>
> And equally important is that pip only really reacts well to version
> capping / pinning if you do it all at once across all your things.
>
> When we had a cap, and raised it, we had to:
>
> A) raise it in low level oslo libs (like oslo.config)
> B) release those libraries with new caps
> C) raise the cap in all the things that used that library
> D) release those libraries with new caps
> E) ... repeat
> ...
> M) raise the cap in all top level openstack server projects
>
> So a dozen library releases could easily be triggered by fixing one cap
> or pin in one low level library, that were no functional changes, they
> were just requirements changes. The only reason M could use the old
> version of A is because pip wouldn't let you install the 2 together. Not
> for any functional reasons.
>
> 	-Sean
>

This thread is now directly related to the upgrade impact being 
discussed in liberty here:

https://review.openstack.org/#/c/255245/

-- 

Thanks,

Matt Riedemann