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
