> On Nov 19, 2015, at 11:24 AM, Matt Riedemann <mrie...@linux.vnet.ibm.com> > wrote: > > > > On 11/19/2015 10:22 AM, Amrith Kumar wrote: >> Just catching up on this thread, have fixes been submitted for this already? >> >> Thanks, >> >> -amrith >> >>> -----Original Message----- >>> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] >>> Sent: Wednesday, November 18, 2015 2:54 PM >>> To: openstack-dev@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 >>>>> <mrie...@linux.vnet.ibm.com <mailto:mrie...@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-requ...@lists.openstack.org?subject:unsubscribe >>>>> >>>>> <http://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 >>>>> >>>> >>> >>> 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- >>> 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 >> > > https://review.openstack.org/#/c/246735/ fixes the problem with trunk > novaclient in the stable/kilo unit tests, but there are other tests failing > due to what look to be issues with mock.open. I haven't dug into those. > > -- > > 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
Now that i’m getting these emails again i can reply. :) I’m looking into these tests now and i’m testing a solution for them. -Craig __________________________________________________________________________ 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