Open Stack

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

Just an update:

Kilo: I think we are OK here now, at least for some projects like nova - 
raising the minimum required neutronclient to >=2.4.0 seems to have 
fixed things.

Juno: We're still blocked on the large ops job:

https://bugs.launchpad.net/openstack-gate/+bug/1482350

I'll probably take a deeper look at options there tomorrow.  lifeless 
left a suggestion in the bug report.

-- 

Thanks,

Matt Riedemann