[openstack-dev] [trove] trove unit tests failing on stable/kilo [imm]

Amrith Kumar amrith at tesora.com
Thu Nov 19 16:22:35 UTC 2015


Just catching up on this thread, have fixes been submitted for this already?

Thanks,

-amrith

> -----Original Message-----
> From: Matt Riedemann [mailto:mriedem at linux.vnet.ibm.com]
> Sent: Wednesday, November 18, 2015 2:54 PM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [trove] trove unit tests failing on stable/kilo
> 
> 
> 
> On 11/18/2015 9:23 AM, Matt Riedemann wrote:
> >
> >
> > On 11/17/2015 10:37 PM, Nikhil Manchanda wrote:
> >> Thanks for putting up that fix Matt.
> >>
> >> The dependency on trunk python-troveclient (for stable/kilo)
> >> definitely seems
> >> screwy-- but I'm wondering if this was done for backwards
> >> compatibility reasons?
> >> (i.e. to ensure the latest version of python-troveclient should be
> >> able to work correctly against all previous releases of trove.)
> >
> > If that was the plan, https://review.openstack.org/#/c/210004/ totally
> > blows that up since it's a backward incompatible change and was
> > released in a minor version rather than a major version.  That change
> > is really what's breaking stable/kilo trove unit tests.
> >
> >>
> >> Either way, I think we should be honoring the requirements specified
> >> for the respective releases in g-r, so I think that this is the right
> >> fix.
> >>
> >> Cheers,
> >> Nikhil
> >>
> >>
> >>
> >> On Tue, Nov 17, 2015 at 7:42 PM, Matt Riedemann
> >> <mriedem at linux.vnet.ibm.com <mailto:mriedem at linux.vnet.ibm.com>>
> wrote:
> >>
> >>
> >>
> >>     On 11/17/2015 9:27 PM, Matt Riedemann wrote:
> >>
> >>
> >>
> >>         On 11/17/2015 9:22 PM, Matt Riedemann wrote:
> >>
> >>             I noticed this failing today:
> >>
> >>
> >> http://logs.openstack.org/81/206681/3/check/gate-trove-
> python27/45d64
> >> 5d/console.html#_2015-11-17_17_07_28_061
> >>
> >>
> >>
> >>
> >>             Looks like https://review.openstack.org/#/c/218701/ and
> >>             maybe the
> >>             dependent python-troveclient change would need to be
> >>             backported to
> >>             stable/kilo (neither are clean backports), or we can just
> >>             skip the test
> >>             on stable/kilo if there is a good reason why it won't work.
> >>
> >>
> >>         I also see that the unit test job on stable/kilo is pulling
> >> in trunk
> >>         python-troveclient:
> >>
> >>
> >> http://logs.openstack.org/81/206681/3/check/gate-trove-
> python27/45d64
> >> 5d/console.html#_2015-11-17_17_07_28_393
> >>
> >>
> >>
> >>         Even though we have troveclient capped at 1.1.0 in kilo g-r:
> >>
> >>
> >> https://github.com/openstack/requirements/blob/stable/kilo/global-req
> >> uirements.txt#L136
> >>
> >>
> >>
> >>         So how is that happening?
> >>
> >>         Oh, because of this:
> >>
> >>
> >> https://github.com/openstack/trove/blob/stable/kilo/test-requirements
> >> .txt#L17
> >>
> >>
> >>
> >>         And that's terrible....why are we doing that?
> >>
> >>
> >>     Attempting to fix here: https://review.openstack.org/#/c/246735/
> >>
> >>
> >>     --
> >>
> >>     Thanks,
> >>
> >>     Matt Riedemann
> >>
> >>
> >>
> >>
> __________________________________________________________
> ___________
> >> _____
> >>
> >>     OpenStack Development Mailing List (not for usage questions)
> >>     Unsubscribe:
> >>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>
> >> <http://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
> >>
> >
> 
> Getting back to root causes, I discussed with a couple of people in IRC and
> wanted to take notes here.
> 
> The root issue was the backward incompatible troveclient change:
> 
> https://review.openstack.org/#/c/210004/
> 
> That was released in 1.3.0 and 1.4.0.  A server side change was made in
> liberty that requires that:
> 
> https://review.openstack.org/#/c/218701/
> 
> The troveclient change is breaking stable/kilo since the server side change
> isn't in stable/kilo. We could backport that, but given global-requirements on
> troveclient in stable/kilo, it's technically invalid:
> 
> https://github.com/openstack/requirements/blob/stable/kilo/global-
> requirements.txt#L136
> 
> python-troveclient>=1.0.7,<1.1.0
> 
> Since it's unit tests only and stable/kilo trove is testing against trunk
> troveclient, maybe we don't care - we just hack the fix and go about our
> merry way.
> 
> I have little stake in trove as a project so it's ultimately up to the project
> drivers.
> 
> The right thing to do, IMO, is revert that backward incompatible troveclient
> change, release that as 1.4.1, restore the change and then release that as 2.0.
> We'd also blacklist 1.3.0 and 1.4.0 in global-requirements.
> 
> Unit tests on trove master and stable/liberty would break once the revert on
> troveclient landed because the trove unit tests require that code in
> troveclient, but that'd be fixed once you revert the revert (since the trove
> unit tests run trunk troveclient, not from released versions). This could be
> short term pain though and it's controllable within the trove core team.
> 
> I think long-term trove should not be unit testing against trunk troveclient,
> since it's a false sense of functionality as we've seen here. Trove should really
> be requiring the same versions of troveclient that are specified in global-
> requirements. Doing that would make this unit test thing a bit messier
> though, but not unmanageable.
> 
> So, I guess the question is, what does the trove team want to do here?
> 
> --
> 
> 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