Open Stack

On 3/8/2016 1:18 PM, Amrith Kumar wrote:
> Matt,
>
> See inline below.
>
> -amrith
>
>> -----Original Message-----
>> From: Matt Riedemann [mailto:mriedem at linux.vnet.ibm.com]
>> Sent: Tuesday, March 08, 2016 2:00 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 12:52 PM, Matt Riedemann wrote:
>>>
>>>
>>> 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-r
>>> equirements.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-requireme
>>> nts.txt#L202
>>
>> I've confirmed that running master (mitaka) unit tests for trove against
>> python-troveclient 1.2.0 don't work:
>>
>> http://paste.openstack.org/show/489719/
>
> [amrith] Just like the bug you listed, this appears to be a case of a broken test. Would you please LP it.
>
>>
>>>
>>>
>>>> 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-polic
>>>>>> y.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
>>
>>
>> __________________________________________________________________________
>> 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
>

Well, the point I'm trying to get to is, I don't think troveclient < 
2.1.0 will work with the trove-api in mitaka.

For example, in my change to revert the slave_of removal in the client:

https://review.openstack.org/#/c/290048/

That fails in the API:

http://logs.openstack.org/48/290048/2/check/gate-trove-functional-dsvm-mysql/ddd3089/logs/screen-tr-api.txt.gz#_2016-03-08_19_30_32_790

"Validation error: instance Additional properties are not allowed 
(u'slave_of' was unexpected)"

So if my client application that I wrote in liberty was using slave_of, 
it's happily working until the cloud that my application is running on 
upgrades to mitaka, then things break.

Part of the issue here is the backward incompatible change in the trove 
API. The other part is, the trove API in mitaka requires 
troveclient>=2.1.0 because that's what removed slave_of.

Right?

I'm trying to sort out what a valid troveclient is for master, because I 
don't really trust what's in global-requirements since trove hasn't been 
testing with those versions, at least not at the lower bound of 1.2.0.

-- 

Thanks,

Matt Riedemann