-----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
