Open Stack

Matt,

As I understand it, you have 4 changes up for review.

    Change [1] seeks to revert the change [6] to python-troveclient on
    master and reinstate the slave_of parameter.

    Change [2] is doing for stable/liberty, the same things that were
    done for master in [9] on master, and [7] on Kilo earlier.

    Change [3] is looking to blacklist python-troveclient 2.1.0 on
    stable/liberty.

    Change [4] is looking to bump the minimum python-troveclient version
    on master to 2.1.0.

Here are three questions I have:

(1) Wouldn't backward compatibility also require that you revert the
other change that removed slave_of on the server [5] ? After all, just
like a python client that calls create() with slave_of, a REST client
could call the endpoint with slave_of. What is the policy for REST API
backward compatibility?

(2) Wouldn't [4] just block 2.1.0 in global-requirements on master
(mitaka)?

(3) Something, potentially your patch set [2], should also fix the test
that is invoking create() with slave_of, no?

-amrith

[1] https://review.openstack.org/290048/
[2] https://review.openstack.org/290023/
[3] https://review.openstack.org/290021/
[4] https://review.openstack.org/290168/
[5] https://review.openstack.org/#/c/245845/
[6] https://review.openstack.org/#/c/245738/
[7] https://review.openstack.org/#/c/246735/

On 03/08/2016 08:24 PM, Matt Riedemann wrote:
>
>
> 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.
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160309/8e829ea9/attachment.pgp>