[openstack-dev] [stable] Kilo gate doesn't like testtools 2.0.0

Matt Riedemann mriedem at linux.vnet.ibm.com
Sat Feb 6 14:56:26 UTC 2016



On 2/6/2016 7:54 AM, Matt Riedemann wrote:
>
>
> On 2/5/2016 11:01 PM, Matthew Treinish wrote:
>>
>>
>> On February 6, 2016 4:29:34 PM GMT+11:00, Matt Riedemann
>> <mriedem at 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-request at 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/
>

Keeping in mind that an os-testr 0.6.1 release would be used in liberty 
and master jobs where testtools is not capped (at least in g-r) but I 
don't think that would cause problems.

-- 

Thanks,

Matt Riedemann




More information about the OpenStack-dev mailing list