[openstack-dev] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506

Amrith Kumar amrith at tesora.com
Tue Mar 8 19:18:15 UTC 2016


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



More information about the OpenStack-dev mailing list