[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