Open Stack

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
>

-- 

Thanks,

Matt Riedemann