See below. > -----Original Message----- > From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] > Sent: Tuesday, March 08, 2016 1:53 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: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/a > > pi/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- > requirements.txt#L174
[amrith] Yes, the server understands replica_of. > > > 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- > requirements.txt#L202 [amrith] My mistake, this specific issue won't cause a problem there. It'll work. > > > 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-policy > >>> .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
