Open Stack

On 8/10/2015 9:40 AM, Matt Riedemann wrote:
>
>
> 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/
>

Cripes, that depends on this fix now:

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

-- 

Thanks,

Matt Riedemann