[openstack-dev] Dependency version pinning [was Re: Pyparsing 2.0 breaking jenkins jobs]

Monty Taylor mordred at inaugust.com
Sat Mar 2 14:31:30 UTC 2013



On 03/01/2013 10:07 AM, Sean Dague wrote:
> On 03/01/2013 05:09 AM, Mark McLoughlin wrote:
>> On Fri, 2013-03-01 at 20:27 +1030, Christopher Yeoh wrote:
>>> On Thu, 28 Feb 2013 13:16:23 +0000
>>> Mark McLoughlin <markmc at redhat.com> wrote:
>>>>> That way we find out about compatibility problems ASAP but we have a
>>>>> controlled way of managing the changes necessary into projects and
>>>>> not end up with the gate stalled for hours at random times.
>>>>
>>>> It's not just about the gate, it's also about the software we ship.
>>>> The ideal is that all our dependencies listed in setup.py are >=
>>>> because that allows our software to be installed in more environments.
>>>>
>>>
>>> That's true, though there's no reason we can't in general ship with >=
>>> dependencies, but have the gate test with specific versions required,
>>> where that version is the latest we know that works (determined through
>>> some automated testing to warn us of problems ahead).
>>
>> I'd like us to be testing with two dependency stacks - both the minimum
>> required versions and the latest available versions - but that's a ways
>> away yet.
>>
>> The instability in the gate is best fixed by only updating the pypi
>> mirror when the update doesn't break the gate. If a pypi mirror update
>> fails, that means something is broken upstream of us and we either need
>> to get the upstream fixed or pin to a specific version.
>>
>> Advantage is we know when something has broken and we can investigate it
>> without the "OMG, the gate is hosed!" pressure.
> 
> Today the mirror isn't strictly enforced. Is there someone working on
> changing that in the near term?

Yes - there is work going in to this. It has a couple of different
streams, and there is also shorter and longer term work and design that
still needs to be done. This is also tied together with work on
openstack/requirements - and I believe it's going to wind up having
impact on how we install requirements for devstack too.

We've put in some summit sessions on the topic - but I'm also working on
writing up thoughts on the entire problem space. (this is one of those
where you really have to understand all of the use cases at the same
time. sigh)



More information about the OpenStack-dev mailing list