Open Stack

On 3/8/2016 12:35 PM, Amrith Kumar wrote:
> Matt,
>
> The correct solution for liberty is that we should fix the tests. Here's why I believe that this is the case.
>
> In pertinent part, the backtrace from your bug includes:
>
> 2016-01-27 07:02:06.777 | File "/home/jenkins/workspace/periodic-trove-python27-liberty/trove/tests/api/replication.py", line 83, in create_slave
> 2016-01-27 07:02:06.777 | slave_of=instance_info.id)
>
> This is in the tests, not the client.
>
> The test is now generating a parameter that the client no longer understands.
>
> For a user, here are the various situations that could occur.
>
> 1. User running python-troveclient from the latest 2.1.0 and a server from liberty. All is good.
> 2. User running an old python-troveclient and a server from liberty. All is good.

Will this work with python-troveclient 1.2.0 which is the minimum 
required troveclient for stable/liberty?

https://github.com/openstack/requirements/blob/stable/liberty/global-requirements.txt#L174

> 3. User running an old python-troveclient and a new server from mitaka, this is not supported.

How is this not supported?  If it's not supported, the minimum required 
version of troveclient in master g-r is wrong, since it hasn't changed 
since liberty:

https://github.com/openstack/requirements/blob/master/global-requirements.txt#L202

> 4. User running a current python-troveclient from the latest 2.1.0 and a server from mitaka, All is good.
>
> What you have here is a case where a test is generating an argument (slave_of) that the client (master, 2.1.0) no longer understands. There's nothing amiss there, except that the test needs to be fixed.
>
> When you get back, let's continue the conversation either in email or IRC #openstack-dev. Looking forward to hearing your feedback on this.
>
> Thanks,
>
> -amrith
>
>
>> -----Original Message-----
>> From: Matt Riedemann [mailto:mriedem at linux.vnet.ibm.com]
>> Sent: Tuesday, March 08, 2016 12:11 PM
>> To: openstack-dev at lists.openstack.org
>> Subject: Re: [openstack-dev] [trove][stable] proboscis tests randomly
>> failing in stable branches; bug 1538506
>>
>>
>>
>> On 3/8/2016 10:17 AM, Matt Riedemann wrote:
>>> This is a call for help on resolving bug 1538506 [1] where the
>>> proboscis tests randomly fail on the stable branches with something
>> like:
>>>
>>> TypeError: create() got an unexpected keyword argument 'slave_of'
>>>
>>> Craig Vyvial has a proposed stable/kilo change [2] but it has some
>>> issues, at least from me as a reviewer of that change.
>>>
>>> The tests are failing the periodic-stable job daily [3].
>>>
>>> Can we get someone to help out with this? Otherwise I'm inclined to
>>> say the tests should be disabled on the stable branches, but that's
>>> pretty drastic.
>>>
>>> Note that this is the kind of thing that breaks stable branch policy,
>>> which is going to be part of a review when applying for the
>>> stable:follows-policy tag. [4]  And the stable:follows-policy tag may
>>> be used to determine when a stable branch for a project goes end of
>>> life if it's not being maintained.
>>>
>>> [1] https://bugs.launchpad.net/trove/+bug/1538506
>>> [2] https://review.openstack.org/#/c/276934/
>>> [3] http://goo.gl/fqf11U
>>> [4]
>>> http://governance.openstack.org/reference/tags/stable_follows-policy.h
>>> tml
>>>
>>
>> This is my solution for liberty, cap python-troveclient<2.1.0 in global-
>> requirements on stable/liberty [1].
>>
>> Then there is a change to trove on stable/liberty to use the g-r version
>> range for python-troveclient for unit tests [2].
>>
>> Alternatively, we could avoid the cap in stable/liberty by:
>>
>> 1. Reverting https://review.openstack.org/#/c/245738/
>> 2. Blacklisting python-troveclient 2.1.0 in g-r 3. Release python-
>> troveclient 2.2.0.
>>
>> It's getting late in the mitaka release to be messing with this though
>> since we're already past client freeze.
>>
>> [1] https://review.openstack.org/#/c/290021/
>> [2] https://review.openstack.org/#/c/290023/
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>>
>> __________________________________________________________________________
>> 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
>
> __________________________________________________________________________
> 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
>

-- 

Thanks,

Matt Riedemann