settingsLogin | Registersettings

Re: [openstack-dev] [trove] trove unit tests failing on stable/kilo [imm]

0 votes

Just catching up on this thread, have fixes been submitted for this already?

Thanks,

-amrith

-----Original Message-----
From: Matt Riedemann [mailto:mriedem@linux.vnet.ibm.com]
Sent: Wednesday, November 18, 2015 2:54 PM
To: openstack-dev@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@linux.vnet.ibm.com mriedem@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@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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Nov 19, 2015 in openstack-dev by Amrith_Kumar (10,500 points)   2 4 4

3 Responses

0 votes

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@linux.vnet.ibm.com]
Sent: Wednesday, November 18, 2015 2:54 PM
To: openstack-dev@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@linux.vnet.ibm.com mriedem@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@lists.openstack.org?subject:unsubscribe

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@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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 19, 2015 by Matt_Riedemann (48,320 points)   3 7 20
0 votes

Thanks Matt, Craig (cp16net) is working on fixing this.

-amrith

-----Original Message-----
From: Matt Riedemann [mailto:mriedem@linux.vnet.ibm.com]
Sent: Thursday, November 19, 2015 12:24 PM
To: openstack-dev@lists.openstack.org
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:mriedem@linux.vnet.ibm.com]
Sent: Wednesday, November 18, 2015 2:54 PM
To: openstack-dev@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@linux.vnet.ibm.com
mriedem@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-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:
 OpenStack-dev-request@lists.openstack.org?subject:unsubscribe

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@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@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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 19, 2015 by Amrith_Kumar (10,500 points)   2 4 4
0 votes

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

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


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 19, 2015 by Vyvial,_Craig (340 points)  
...