Open Stack

On 8/7/2015 7:41 PM, Matt Riedemann wrote:
>
>
> On 8/7/2015 5:27 PM, Kyle Mestery wrote:
>> On Fri, Aug 7, 2015 at 4:09 PM, Matt Riedemann
>> <mriedem at linux.vnet.ibm.com <mailto:mriedem at linux.vnet.ibm.com>> wrote:
>>
>>
>>
>>     On 8/7/2015 3:52 PM, Matt Riedemann 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.
>>
>>         b) Install cinder in the large ops job on stable/juno.
>>
>>         c) Disable the large ops job for stable/juno.
>>
>>
>>         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/.
>>
>>
>>     OK, the problem is that neutronclient doesn't get updated on the new
>>     kilo side of grenade past 2.3.12 because it satisfies the
>>     requirement for kilo:
>>
>>
>> https://github.com/openstack/requirements/blob/stable/kilo/global-requirements.txt#L132
>>
>>
>>     python-neutronclient>=2.3.11,<2.5.0
>>
>>     But since neutronclient 2.3.12 caps things for juno, we can't use it
>>     on kilo due to the conflict and then kaboom.
>>
>>
>> So, 2.3.12 was explicitely for Juno, and not for Kilo. In fact, the
>> existing 2.3.11 client for Juno was failing due to some other oslo
>> library (I'd have to dig it out). It seems we want Kilo requirements to
>> be this:
>>
>> python-neutronclient>=2.4.0,<2.5.0
>
> adam_g and I talked about this in IRC as a solution, but I want to avoid
> raising the minimum required version of a library in stable, mostly in
> case that screws up packagers that are frozen for stable releases and
> aren't shipping newer versions of libraries as long as the old minimum
> version satisfied the code dependencies.
>
> Since there are no code issues requiring bumping the minimum required
> version on stable/kilo, just our dep processing issues, I'd really like
> to avoid that.
>
> However, at this point I'm not sure what other alternatives there are -
> kind of fried from looking at this stuff for two days.
>
>>
>> I won't be able to submit a patch which does this for a few more hours,
>> if someone beats me to it, please copy me on the patch and/or reply on
>> this thread.
>>
>> Thanks for digging this one out Matt!
>>
>> Kyle
>>
>>
>>
>>         Need some help here.
>>
>>
>>     --
>>
>>     Thanks,
>>
>>     Matt Riedemann
>>
>>
>>
>> __________________________________________________________________________
>>
>>     OpenStack Development Mailing List (not for usage questions)
>>     Unsubscribe:
>>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>
>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> __________________________________________________________________________
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>

What I do know is we need to be better about bumping the minor version 
in a release rather than the patch version all of the time - we've kind 
of painted ourselves into a corner a few times here with leaving no 
wiggle room for patch releases on stable branches.

-- 

Thanks,

Matt Riedemann