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 <mrie...@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/
--
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
