Open Stack

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/

-- 

Thanks,

Matt Riedemann