Open Stack

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
>
>

-- 

Thanks,

Matt Riedemann