Open Stack

On 3/8/2016 4:44 PM, Matt Riedemann wrote:
>
>
> On 3/8/2016 3:17 PM, Matt Riedemann wrote:
>>
>>
>> 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.
>>
>
> Here is a change that bumps the minimum required version of
> python-troveclient for mitaka to 2.1.0:
>
> https://review.openstack.org/#/c/290168/
>

Here is my preferred option now.

1. Revert the slave_of removal from python-troveclient and provide it as 
a compat shim until liberty-eol:

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

If slave_of is used, a deprecation warning is emitted (which we should 
have been doing when this was deprecated in the first place). It also 
never sends slave_of to the API, it's just a proxy to replica_of. So 
this should work with both the liberty and mitaka versions of the trove API.

2. Block python-troveclient 2.1.0 from stable/liberty g-r:

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

That blocks the bad 2.1.0 version from being used in stable/liberty 
which is needed for...

3. Using the g-r versions of python-troveclient when testing on 
stable/liberty:

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

If trove is following global-requirements, it should be using the 
versions of python-troveclient from global-requirements rather than 
installing it from the latest tarball on trunk. master and stable/kilo 
are already doing this.

-- 

Thanks,

Matt Riedemann