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-requirements.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-requirements.txt#L202
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
