Just catching up on this thread, have fixes been submitted for this already?
Thanks, -amrith > -----Original Message----- > From: Matt Riedemann [mailto:[email protected]] > Sent: Wednesday, November 18, 2015 2:54 PM > To: [email protected] > 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 > >> <[email protected] <mailto:[email protected]>> > 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: > >> [email protected]?subject:unsubscribe > >> > >> <http://OpenStack-dev- > [email protected]?subject:unsubscribe> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > >> > >> > __________________________________________________________ > ___________ > >> _____ > >> > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: > >> [email protected]?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- > [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
