Open Stack

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/

-- 

Thanks,

Matt Riedemann