Open Stack

On 8/9/2015 7:16 PM, Matt Riedemann wrote:
>
>
> On 8/9/2015 7:09 PM, Robert Collins wrote:
>> On 8 August 2015 at 08:52, Matt Riedemann <mriedem at linux.vnet.ibm.com>
>> wrote:
>>> Well it's a Friday afternoon so you know what that means, emails
>>> about the
>>> stable branches being all busted to pieces in the gate.
>>>
>>> Tracking in the usual place:
>>>
>>> https://etherpad.openstack.org/p/stable-tracker
>>>
>>> Since things are especially fun the last two days I figured it was
>>> time for
>>> a notification to the -dev list.
>>>
>>> Both are basically Juno issues.
>>>
>>> 1. The large ops job is busted because of some uncapped dependencies in
>>> python-openstackclient 1.0.1.
>>>
>>> https://bugs.launchpad.net/openstack-gate/+bug/1482350
>>>
>>> The fun thing here is g-r is capping osc<=1.0.1 and there is already
>>> a 1.0.2
>>> version of osc, so we can't simply cap osc in a 1.0.2 and raise that
>>> in g-r
>>> for stable/juno (we didn't leave ourselves any room for bug fixes).
>>>
>>> We talked about an osc 1.0.1.1 but pbr>=0.11 won't allow that because it
>>> breaks semver.
>>>
>>> The normal dsvm jobs are OK because they install cinder and cinder
>>> installs
>>> the dependencies that satisfy everything so we don't hit the osc
>>> issue.  The
>>> large ops job doesn't use cinder so it doesn't install it.
>>>
>>> Options:
>>>
>>> a) Somehow use a 1.0.1.post1 version for osc.  Would require input from
>>> lifeless.
>>
>> This is really tricky. postN versions are a) not meant to change
>> anything functional (see PEP-440) and b) are currently mapped to devN
>> by pbr for compatibility with pbr 0.10.x which had the unenviable task
>> of dealing with PEP-440 going live in pip.
>>
>>> b) Install cinder in the large ops job on stable/juno.
>>
>> That would seem fine IMO.
>>
>>> c) Disable the large ops job for stable/juno.
>>
>> I'd rather not do this.
>>
>>> 2. grenade on kilo blows up because python-neutronclient 2.3.12 caps
>>> oslo.serialization at <=1.2.0, keystonemiddleware 1.5.2 is getting
>>> pulled in
>>> which pulls in oslo.serialization 1.4.0 and things fall apart.
>>>
>>> https://bugs.launchpad.net/python-neutronclient/+bug/1482758
>>>
>>> I'm having a hard time unwinding this one since it's a grenade job.
>>> I know
>>> the failures line up with the neutronclient 2.3.12 release which caps
>>> requirements on stable/juno:
>>>
>>> https://review.openstack.org/#/c/204654/.
>>>
>>> Need some help here.
>>
>> I think it would be entirely appropriate to bump the lower bound of
>> neutronclient in kilo: running with the version with juno caps *isn't
>> supported* full stop, across the board. Its a bug that we have a bad
>> lower bound there.
>
> On Friday, adam_g and I weren't sure what the policy was on overlapping
> upper bounds for juno and lower bounds for kilo, but yeah, my first
> reaction was that's bonkers and anything that's working that way today
> is just working as a fluke and could wedge us the same way at any point.
>
> The reason I'd prefer to not raise the minimum required version of a
> library in stable g-r is simply for those packagers/distros that are
> basically frozen on the versions of libraries they are providing for
> kilo and I'd like to not make them arbitrarily move up just because of
> our screw ups.
>
> Apparently in our case (the product I work on), we already ship
> neutronclient 2.4.0 in our kilo release so I guess it'd wouldn't be the
> end of the world for us.
>
>>
>> -Rob
>>
>>
>

We're going with raising the minimum required neutronclient for kilo to 
2.4.0:

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

-- 

Thanks,

Matt Riedemann