On 2/5/2016 11:01 PM, Matthew Treinish wrote:
On February 6, 2016 4:29:34 PM GMT+11:00, Matt Riedemann
<mrie...@linux.vnet.ibm.com> wrote:
On 2/4/2016 11:23 PM, Tony Breeds wrote:
Hi All,
Just a quick heads up that the kilo gate (and therefore anything
that
relies on kilo)[1] is a little busted.
This was originally noticed in 1541879[2] and a quick cap for g-r was
proposed,
however if my analysis is correct this can't land because of
1542164[3].
testtools 2.0.0 was released 2016-02-04 and has a hard requirement on
on
fixtures >=1.3.0 which isn't compatible with stable/kilo's
global-requirements.
We can't land an update to requirements to cap testtools as we
install
testtools (2.0.0) when we install os-testr[4]. Nothing we install
from git in a
typical devstack run requires testtools (it's only listed in
test-requirements.txt) so we end up with 2.0.0.
Then when we run services, the requirements kick in and balk because,
as an
example, keystone requires fixtures>=0.3.14,<1.3.0 and testtools
requires
fixtures>=1.3.0
The way forward is land https://review.openstack.org/276580 and
https://review.openstack.org/276275/ This will unblock the gate and
buy us time
to work out the right way to make kilo, os-testr and testtools play
nice.
There are a few options none are very nice and generate work at a
time when the
key players are travelling.
Of course I could be way off base and there is a much easier option.
Yours Tony.
[1] liberty grenade and neutron master seems to run a bunch of *-kilo
jobs
[2] https://bugs.launchpad.net/neutron/+bug/1541879
[3] https://bugs.launchpad.net/devstack/+bug/1542164
[4] As we're pip_install'ing it we don't massage the requirements to
match g-r.
We could update the gate to install os-testr from git as a work
around but
that's not what I chose to do
If os-testr is causing problems in stable/kilo it's only recently been
added [1]. That was for a devstack backport, which is arguably nice to
have but not necessary, so we could revert those if needed.
os-testr isn't causing the issue, it's just the first thing that installs
testtools after we backported subunit output to kilo devstack. If you look at
the requirements file for os-testr:
https://github.com/openstack/os-testr/blob/master/requirements.txt
it isn't requiring 2.0 so if we cap < 2 in g-r it should fix the issue. If we
revert the devstack subunit patch it'll just move the breakage to later in the job
when testtools gets installed later.
Anyway, mtreinish is traveling so the next person to probably look at
this is sdague since he's got +2 on devstack on stable and all other
stable branch stuff, like the g-r cap on testtools (which is probably
good to have regardless of what we do with os-testr in stable/kilo).
I just approved the g-r cap, that should unwedge things.
[1] https://review.openstack.org/#/c/273192/
__________________________________________________________________________
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
To remove the devstack workaround [1] we have to create a stable/kilo
branch for os-testr (from the 0.6.0 tag probably since that's what's
currently being used in kilo jobs), sync the g-r change to cap
testtools, and then release that as 0.6.1 - right?
[1] https://review.openstack.org/#/c/276580/
--
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
