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
<mrie...@linux.vnet.ibm.com <mailto:mrie...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
