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/45d645d/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/45d645d/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-requirements.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://[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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
