Thanks Matt, Craig (cp16net) is working on fixing this. -amrith
> -----Original Message----- > From: Matt Riedemann [mailto:[email protected]] > Sent: Thursday, November 19, 2015 12:24 PM > To: [email protected] > Subject: Re: [openstack-dev] [trove] trove unit tests failing on stable/kilo > [imm] > > > > 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:[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-r > >>>> eq > >>>> uirements.txt#L136 > >>>> > >>>> > >>>> > >>>> So how is that happening? > >>>> > >>>> Oh, because of this: > >>>> > >>>> > >>>> https://github.com/openstack/trove/blob/stable/kilo/test- > requiremen > >>>> ts > >>>> .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 > > > > 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- > [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
