Open Stack

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
>> <mriedem at linux.vnet.ibm.com <mailto:mriedem at 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/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:
>>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>
>> <http://OpenStack-dev-request@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-request at 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