Open Stack

> On Nov 19, 2015, at 11:24 AM, Matt Riedemann <mriedem at 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:mriedem at linux.vnet.ibm.com]
>>> Sent: Wednesday, November 18, 2015 2:54 PM
>>> To: openstack-dev at 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
>>>>> <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/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-request at lists.openstack.org?subject:unsubscribe
>>>>> 
>>>>> <http://OpenStack-dev-
>>> request at 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
>>> 
>>> 
>>> __________________________________________________________
>>> ________________
>>> 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
>> 
>> __________________________________________________________________________
>> 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
>> 
> 
> 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-request at 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