Matt, See inline below.
-amrith > -----Original Message----- > From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] > Sent: Tuesday, March 08, 2016 2:00 PM > To: openstack-dev@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:mrie...@linux.vnet.ibm.com] > >>> Sent: Tuesday, March 08, 2016 12:11 PM > >>> To: openstack-dev@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
