Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
This is in testtools 1.4.0 but I can't upload it to pypi atm - its 500ing. :( -Rob On 17 November 2014 18:41, Nikhil Manchanda nik...@manchanda.me wrote: Thanks Robert! Looks like it failed the Travis CI job due to an intermittent connectivity issue and I don't have the rights to kick-off the job again. I would appreciate it if you could kick it off again when you get a chance. Cheers, Nikhil On Sun, Nov 16, 2014 at 6:44 PM, Robert Collins robe...@robertcollins.net wrote: On 17 November 2014 11:29, Alan Pevec ape...@gmail.com wrote: 2014-11-15 23:06 GMT+01:00 Robert Collins robe...@robertcollins.net: We did find a further issue, which was due to the use of setUpClass in tempest (a thing that testtools has never supported per se - its always been a happy accident that it worked). I've hopefully fixed that in 1.3.0 and we're babysitting tempest now to see. Trove stable/juno py26 (py27 works) unit tests are failing with testtools 1.3.0 http://logs.openstack.org/periodic-stable/periodic-trove-python26-juno/fcf4db2/testr_results.html.gz ... File /home/jenkins/workspace/periodic-trove-python26-juno/trove/tests/unittests/mgmt/test_models.py, line 60, in setUpClass super(MockMgmtInstanceTest, cls).setUpClass() AttributeError: 'super' object has no attribute 'setUpClass' pip freeze diff since last good report is: -testtools==1.1.0 +testtools==1.3.0 +unittest2==0.8.0 Any ideas? https://github.com/testing-cabal/testtools/pull/125 Will fix that, and I'll cut 1.4.0 with that in it once I get a peer review. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 11/15/2014 02:51 PM, Robert Collins wrote: It probably needs to be backed out of stable/icehouse. The issue is that we were installing unittest2 via distro packages *and* testtools new dependency on unittest2 did not express a minimum version. We're just about to issue 1.2.1 which will have such a minimum version. And for the record, this was released on saturday, not friday :). Damn you and your living in the future! :) Honestly, though, the requirements change was !=1.2.0, so it does the right thing of just blocking the 1 version that depending on new unittest2 but isn't explicit about it. I made it very narrow for a reason, as I assumed it would get fixed in the next released version, and we'd be rolling again. It looks like 1.3.0 did just that, which is great. Thanks for looking at this and getting a fix out Robert. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 11/16/2014 06:11 PM, Robert Collins wrote: On 17 November 2014 11:29, Alan Pevec ape...@gmail.com wrote: 2014-11-15 23:06 GMT+01:00 Robert Collins robe...@robertcollins.net: We did find a further issue, which was due to the use of setUpClass in tempest (a thing that testtools has never supported per se - its always been a happy accident that it worked). I've hopefully fixed that in 1.3.0 and we're babysitting tempest now to see. Trove stable/juno py26 (py27 works) unit tests are failing with testtools 1.3.0 http://logs.openstack.org/periodic-stable/periodic-trove-python26-juno/fcf4db2/testr_results.html.gz ... File /home/jenkins/workspace/periodic-trove-python26-juno/trove/tests/unittests/mgmt/test_models.py, line 60, in setUpClass super(MockMgmtInstanceTest, cls).setUpClass() AttributeError: 'super' object has no attribute 'setUpClass' pip freeze diff since last good report is: -testtools==1.1.0 +testtools==1.3.0 +unittest2==0.8.0 Any ideas? The use of unittest2 in the plumbing means we're now calling setUpClass on 2.6 which we were not doing before. However there is no implementation of setUpClass in the testtools base class, which leads to the error you are seeing. We can fix that by subclassing unittest2.TestCase in testtools' TestCase. I'll put a patch together today. -Rob We don't support 2.6 any more in OpenStack. If we decide to pin testtools on stable/*, we could just let this be. Fixing it is also fine. But I wouldn't mind just moving on here and letting the 2.6 bits die with vigor. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 11/17/2014 06:09 AM, Sean Dague wrote:
On 11/16/2014 06:11 PM, Robert Collins wrote:
On 17 November 2014 11:29, Alan Pevec ape...@gmail.com wrote:
2014-11-15 23:06 GMT+01:00 Robert Collins robe...@robertcollins.net:
We did find a further issue, which was due to the use of setUpClass in
tempest (a thing that testtools has never supported per se - its
always been a happy accident that it worked). I've hopefully fixed
that in 1.3.0 and we're babysitting tempest now to see.
Trove stable/juno py26 (py27 works) unit tests are failing with testtools
1.3.0
http://logs.openstack.org/periodic-stable/periodic-trove-python26-juno/fcf4db2/testr_results.html.gz
...
File
/home/jenkins/workspace/periodic-trove-python26-juno/trove/tests/unittests/mgmt/test_models.py,
line 60, in setUpClass
super(MockMgmtInstanceTest, cls).setUpClass()
AttributeError: 'super' object has no attribute 'setUpClass'
pip freeze diff since last good report is:
-testtools==1.1.0
+testtools==1.3.0
+unittest2==0.8.0
Any ideas?
The use of unittest2 in the plumbing means we're now calling
setUpClass on 2.6 which we were not doing before.
However there is no implementation of setUpClass in the testtools base
class, which leads to the error you are seeing.
We can fix that by subclassing unittest2.TestCase in testtools'
TestCase. I'll put a patch together today.
-Rob
We don't support 2.6 any more in OpenStack. If we decide to pin
testtools on stable/*, we could just let this be.
We still support 2.6 on the python clients and oslo libraries - but
indeed not for trove itself with master.
Fixing it is also fine. But I wouldn't mind just moving on here and
letting the 2.6 bits die with vigor.
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF:Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
We don't support 2.6 any more in OpenStack. If we decide to pin testtools on stable/*, we could just let this be. We still support 2.6 on the python clients and oslo libraries - but indeed not for trove itself with master. What Andreas said, also testtools claims testtools gives you the very latest in unit testing technology in a way that will work with Python 2.6, 2.7, 3.1 and 3.2. so it should be fixed, OpenStack or not. Cheers, Alan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 11/17/2014 07:26 AM, Alan Pevec wrote: We don't support 2.6 any more in OpenStack. If we decide to pin testtools on stable/*, we could just let this be. We still support 2.6 on the python clients and oslo libraries - but indeed not for trove itself with master. What Andreas said, also testtools claims testtools gives you the very latest in unit testing technology in a way that will work with Python 2.6, 2.7, 3.1 and 3.2. so it should be fixed, OpenStack or not. Well, the python 2.6 support was only added for OpenStack. And I think it's fine to drop that burden now that we don't need it (as long as we pin appropriately). -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On Nov 17, 2014, at 7:46 AM, Sean Dague s...@dague.net wrote: On 11/17/2014 07:26 AM, Alan Pevec wrote: We don't support 2.6 any more in OpenStack. If we decide to pin testtools on stable/*, we could just let this be. We still support 2.6 on the python clients and oslo libraries - but indeed not for trove itself with master. What Andreas said, also testtools claims testtools gives you the very latest in unit testing technology in a way that will work with Python 2.6, 2.7, 3.1 and 3.2. so it should be fixed, OpenStack or not. Well, the python 2.6 support was only added for OpenStack. And I think it's fine to drop that burden now that we don't need it (as long as we pin appropriately). We do still need it for some projects, though. The master branches of the servers are off of 2.6, but the master branches of the Oslo libraries are still tested there to make backports easier (and possibly not require them at all of a new version of a lib fixes an issue without breaking anything else). Oslo will continue testing libraries on 2.6 as long as the stable branches that need it are still supported. Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 18 November 2014 01:46, Sean Dague s...@dague.net wrote: On 11/17/2014 07:26 AM, Alan Pevec wrote: We don't support 2.6 any more in OpenStack. If we decide to pin testtools on stable/*, we could just let this be. We still support 2.6 on the python clients and oslo libraries - but indeed not for trove itself with master. What Andreas said, also testtools claims testtools gives you the very latest in unit testing technology in a way that will work with Python 2.6, 2.7, 3.1 and 3.2. so it should be fixed, OpenStack or not. Well, the python 2.6 support was only added for OpenStack. And I think it's fine to drop that burden now that we don't need it (as long as we pin appropriately). Huh? No :) - testtools had Python 2.6 support long before OpenStack existed :) - testtools has kept 2.6 support because a) its easy and b) there are still groups (like but not limited to OpenStack) that care about it. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
2014-11-15 23:06 GMT+01:00 Robert Collins robe...@robertcollins.net: We did find a further issue, which was due to the use of setUpClass in tempest (a thing that testtools has never supported per se - its always been a happy accident that it worked). I've hopefully fixed that in 1.3.0 and we're babysitting tempest now to see. Trove stable/juno py26 (py27 works) unit tests are failing with testtools 1.3.0 http://logs.openstack.org/periodic-stable/periodic-trove-python26-juno/fcf4db2/testr_results.html.gz ... File /home/jenkins/workspace/periodic-trove-python26-juno/trove/tests/unittests/mgmt/test_models.py, line 60, in setUpClass super(MockMgmtInstanceTest, cls).setUpClass() AttributeError: 'super' object has no attribute 'setUpClass' pip freeze diff since last good report is: -testtools==1.1.0 +testtools==1.3.0 +unittest2==0.8.0 Any ideas? Cheers, Alan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 17 November 2014 11:29, Alan Pevec ape...@gmail.com wrote: 2014-11-15 23:06 GMT+01:00 Robert Collins robe...@robertcollins.net: We did find a further issue, which was due to the use of setUpClass in tempest (a thing that testtools has never supported per se - its always been a happy accident that it worked). I've hopefully fixed that in 1.3.0 and we're babysitting tempest now to see. Trove stable/juno py26 (py27 works) unit tests are failing with testtools 1.3.0 http://logs.openstack.org/periodic-stable/periodic-trove-python26-juno/fcf4db2/testr_results.html.gz ... File /home/jenkins/workspace/periodic-trove-python26-juno/trove/tests/unittests/mgmt/test_models.py, line 60, in setUpClass super(MockMgmtInstanceTest, cls).setUpClass() AttributeError: 'super' object has no attribute 'setUpClass' pip freeze diff since last good report is: -testtools==1.1.0 +testtools==1.3.0 +unittest2==0.8.0 Any ideas? The use of unittest2 in the plumbing means we're now calling setUpClass on 2.6 which we were not doing before. However there is no implementation of setUpClass in the testtools base class, which leads to the error you are seeing. We can fix that by subclassing unittest2.TestCase in testtools' TestCase. I'll put a patch together today. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 17 November 2014 11:29, Alan Pevec ape...@gmail.com wrote: 2014-11-15 23:06 GMT+01:00 Robert Collins robe...@robertcollins.net: We did find a further issue, which was due to the use of setUpClass in tempest (a thing that testtools has never supported per se - its always been a happy accident that it worked). I've hopefully fixed that in 1.3.0 and we're babysitting tempest now to see. Trove stable/juno py26 (py27 works) unit tests are failing with testtools 1.3.0 http://logs.openstack.org/periodic-stable/periodic-trove-python26-juno/fcf4db2/testr_results.html.gz ... File /home/jenkins/workspace/periodic-trove-python26-juno/trove/tests/unittests/mgmt/test_models.py, line 60, in setUpClass super(MockMgmtInstanceTest, cls).setUpClass() AttributeError: 'super' object has no attribute 'setUpClass' pip freeze diff since last good report is: -testtools==1.1.0 +testtools==1.3.0 +unittest2==0.8.0 Any ideas? https://github.com/testing-cabal/testtools/pull/125 Will fix that, and I'll cut 1.4.0 with that in it once I get a peer review. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
Thanks Robert! Looks like it failed the Travis CI job due to an intermittent connectivity issue and I don't have the rights to kick-off the job again. I would appreciate it if you could kick it off again when you get a chance. Cheers, Nikhil On Sun, Nov 16, 2014 at 6:44 PM, Robert Collins robe...@robertcollins.net wrote: On 17 November 2014 11:29, Alan Pevec ape...@gmail.com wrote: 2014-11-15 23:06 GMT+01:00 Robert Collins robe...@robertcollins.net: We did find a further issue, which was due to the use of setUpClass in tempest (a thing that testtools has never supported per se - its always been a happy accident that it worked). I've hopefully fixed that in 1.3.0 and we're babysitting tempest now to see. Trove stable/juno py26 (py27 works) unit tests are failing with testtools 1.3.0 http://logs.openstack.org/periodic-stable/periodic-trove-python26-juno/fcf4db2/testr_results.html.gz ... File /home/jenkins/workspace/periodic-trove-python26-juno/trove/tests/unittests/mgmt/test_models.py, line 60, in setUpClass super(MockMgmtInstanceTest, cls).setUpClass() AttributeError: 'super' object has no attribute 'setUpClass' pip freeze diff since last good report is: -testtools==1.1.0 +testtools==1.3.0 +unittest2==0.8.0 Any ideas? https://github.com/testing-cabal/testtools/pull/125 Will fix that, and I'll cut 1.4.0 with that in it once I get a peer review. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] testtools 1.2.0 release breaks the world
Testtools 1.2.0 release apparently broke subunit.run discover --list which breaks the way that tempest calls the test chain. No tempest runs have passed since it's release. https://review.openstack.org/#/c/134705/ is a requirements pin, though I think because of grenade this is actually going to have to be laddered up from icehouse = juno = master. https://review.openstack.org/#/q/I2f8737b44c703c3094d6bbb6580993f86a571934,n,z It's probably half a day babysitting getting all the pins in place to make the world work again. I'm offline from here on out for the weekend, but I'll put a +2/+A on all of these so if someone wants to recheck them in the right order to land them, they can get things fixed. Also... lets try not to release libraries on Fridays before disappearing for the weekend... please. Pretty please. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
Sean, I can baby sit these 3 thanks, dims On Sat, Nov 15, 2014 at 9:25 AM, Sean Dague s...@dague.net wrote: Testtools 1.2.0 release apparently broke subunit.run discover --list which breaks the way that tempest calls the test chain. No tempest runs have passed since it's release. https://review.openstack.org/#/c/134705/ is a requirements pin, though I think because of grenade this is actually going to have to be laddered up from icehouse = juno = master. https://review.openstack.org/#/q/I2f8737b44c703c3094d6bbb6580993f86a571934,n,z It's probably half a day babysitting getting all the pins in place to make the world work again. I'm offline from here on out for the weekend, but I'll put a +2/+A on all of these so if someone wants to recheck them in the right order to land them, they can get things fixed. Also... lets try not to release libraries on Fridays before disappearing for the weekend... please. Pretty please. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 2014-11-15 09:25:54 -0500 (-0500), Sean Dague wrote: Testtools 1.2.0 release apparently broke subunit.run discover --list [...] Also... lets try not to release libraries on Fridays before disappearing for the weekend... please. Pretty please. Also reported upstream as https://github.com/testing-cabal/testtools/issues/121 in case any of the cabal stuck around for the weekend to keep an eye on things. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 15 November 2014 14:25, Sean Dague s...@dague.net wrote: Testtools 1.2.0 release apparently broke subunit.run discover --list which breaks the way that tempest calls the test chain. No tempest runs have passed since it's release. https://review.openstack.org/#/c/134705/ is a requirements pin, though I think because of grenade this is actually going to have to be laddered up from icehouse = juno = master. https://review.openstack.org/#/q/I2f8737b44c703c3094d6bbb6580993f86a571934,n,z It's probably half a day babysitting getting all the pins in place to make the world work again. I'm offline from here on out for the weekend, but I'll put a +2/+A on all of these so if someone wants to recheck them in the right order to land them, they can get things fixed. Also... lets try not to release libraries on Fridays before disappearing for the weekend... please. Pretty please. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev This change has landed in stable/icehouse but... stable/juno is currently blocked by oslo.messaging Master which introduces oslo.middleware, which is not part of stable/juno. I have added pinning to stable/juno global-requirements via https://review.openstack.org/#/c/134727/ This should unblock stable/juno, allowing this to progress. Please be reviewing :) -- Kind Regards, Dave Walker ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
It probably needs to be backed out of stable/icehouse. The issue is that we were installing unittest2 via distro packages *and* testtools new dependency on unittest2 did not express a minimum version. We're just about to issue 1.2.1 which will have such a minimum version. And for the record, this was released on saturday, not friday :). -Rob On 16 November 2014 08:38, Dave Walker em...@daviey.com wrote: On 15 November 2014 14:25, Sean Dague s...@dague.net wrote: Testtools 1.2.0 release apparently broke subunit.run discover --list which breaks the way that tempest calls the test chain. No tempest runs have passed since it's release. https://review.openstack.org/#/c/134705/ is a requirements pin, though I think because of grenade this is actually going to have to be laddered up from icehouse = juno = master. https://review.openstack.org/#/q/I2f8737b44c703c3094d6bbb6580993f86a571934,n,z It's probably half a day babysitting getting all the pins in place to make the world work again. I'm offline from here on out for the weekend, but I'll put a +2/+A on all of these so if someone wants to recheck them in the right order to land them, they can get things fixed. Also... lets try not to release libraries on Fridays before disappearing for the weekend... please. Pretty please. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev This change has landed in stable/icehouse but... stable/juno is currently blocked by oslo.messaging Master which introduces oslo.middleware, which is not part of stable/juno. I have added pinning to stable/juno global-requirements via https://review.openstack.org/#/c/134727/ This should unblock stable/juno, allowing this to progress. Please be reviewing :) -- Kind Regards, Dave Walker ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 15 November 2014 19:51, Robert Collins robe...@robertcollins.net wrote: It probably needs to be backed out of stable/icehouse. The issue is that we were installing unittest2 via distro packages *and* testtools new dependency on unittest2 did not express a minimum version. We're just about to issue 1.2.1 which will have such a minimum version. And for the record, this was released on saturday, not friday :). -Rob We've discussed this on IRC, but I fail to see how this is an appropriate fix for stable/* . This would mean introducing new minima to stable branches, which for stable branches is totally inappropriate. This causes the effect of both distros and deployers requiring a higher version which they have not planned for. If we pin oslo.messaging (which is what we started agreeing in Paris), this problems goes away. -- Kind Regards, Dave Walker ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 2014-11-16 08:51:34 +1300 (+1300), Robert Collins wrote: [...] The issue is that we were installing unittest2 via distro packages *and* testtools new dependency on unittest2 did not express a minimum version. [...] BTW, patches to stop installing unittest2 from distro packages in devstack: https://review.openstack.org/#/q/Ib0e27fd,n,z -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 16 November 2014 03:25, Sean Dague s...@dague.net wrote: Testtools 1.2.0 release apparently broke subunit.run discover --list which breaks the way that tempest calls the test chain. No tempest runs have passed since it's release. https://review.openstack.org/#/c/134705/ is a requirements pin, though I think because of grenade this is actually going to have to be laddered up from icehouse = juno = master. https://review.openstack.org/#/q/I2f8737b44c703c3094d6bbb6580993f86a571934,n,z It's probably half a day babysitting getting all the pins in place to make the world work again. I'm offline from here on out for the weekend, but I'll put a +2/+A on all of these so if someone wants to recheck them in the right order to land them, they can get things fixed. Also... lets try not to release libraries on Fridays before disappearing for the weekend... please. Pretty please. So this has tweaked me - I'm going to rant a little here. It wasn't Friday - it was saturday, when I had some time to do personal stuff and instead chose to push forward on a long arc that has been blocking oslo.db changes for a couple months. I released knowing I'd need to be around to follow up, and the very first thing I did when I got up Sunday morning after dealing with nappies etc was to check for fallout. The release was thoroughly tested upstream, and I explicitly tested it with OpenStack trees as well. I didn't disappear for the weekend, and I didn't even disappear straight to bed... and given how well you know me, you know that I rarely do disappear fully *anyway*, and finally - I'm reachable 24x7 if things really need that (but no-one rang me so clearly its not panic button time) - nor did anyone ask any of the other other testing-cabal committers to do an urgent action. And, and this is perhaps the most annoying aspect, noone in OpenStack tried to reproduce this upstream (which is a 4 command test - make a virtualenv, pip install, cd to a tree, perform discovery) and if they had, such a hypothetical person would have seen that the issue *isn't* testtools, its the use of system-site-packages permitting the old (0.5.1 - current is 0.8.0) unittest2 causing the issue. And thats something thats entirely in the OpenStack space to fix - not upstream. So by going 'oh its testtools problem', 8 or so hours when it could have been fixed have passed with noone looking at it. I totally get the omg its broken and that that makes everyone unhappy when it happens. However I don't like the feeling of being accused of irresponsibility when I was still around for some time (just not at 02:58 am when I was first pinged ( sdague lifeless: https://review.openstack.org/#/c/134705/ should you actually be checking in this weekend). I think everyone is aware that releases have some risk, and doing them cavalierly would be bad. But running with stale dependencies isn't going to be part of the test matrix upstream, since the entire project goal is to fold all its learning into upstream: as things move upstream we have to depend on newer releases of those components (via things like unittest2, importlib2, traceback2 etc etc). -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 16 November 2014 09:03, Dave Walker em...@daviey.com wrote: On 15 November 2014 19:51, Robert Collins robe...@robertcollins.net wrote: It probably needs to be backed out of stable/icehouse. The issue is that we were installing unittest2 via distro packages *and* testtools new dependency on unittest2 did not express a minimum version. We're just about to issue 1.2.1 which will have such a minimum version. And for the record, this was released on saturday, not friday :). -Rob We've discussed this on IRC, but I fail to see how this is an appropriate fix for stable/* . This would mean introducing new minima to stable branches, which for stable branches is totally inappropriate. This causes the effect of both distros and deployers requiring a higher version which they have not planned for. If we pin oslo.messaging (which is what we started agreeing in Paris), this problems goes away. Huh? I think you're working a different bug, no? The testtools thing is what I thought this thread was about :) The oslo.messaging/middleware thing is separate but both are happening at the same time on juno/stable. I was only referring to backing out a pin of testtools - which is needed because with single-version-tempest we can't pin any of tempests dependencies in just stable, we have to have the pins be consistent across all versions tested by tempest (with the current install strategy). -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 15 November 2014 20:23, Robert Collins robe...@robertcollins.net wrote: On 16 November 2014 09:03, Dave Walker em...@daviey.com wrote: On 15 November 2014 19:51, Robert Collins robe...@robertcollins.net wrote: It probably needs to be backed out of stable/icehouse. The issue is that we were installing unittest2 via distro packages *and* testtools new dependency on unittest2 did not express a minimum version. We're just about to issue 1.2.1 which will have such a minimum version. And for the record, this was released on saturday, not friday :). -Rob We've discussed this on IRC, but I fail to see how this is an appropriate fix for stable/* . This would mean introducing new minima to stable branches, which for stable branches is totally inappropriate. This causes the effect of both distros and deployers requiring a higher version which they have not planned for. If we pin oslo.messaging (which is what we started agreeing in Paris), this problems goes away. Huh? I think you're working a different bug, no? The testtools thing is what I thought this thread was about :) The oslo.messaging/middleware thing is separate but both are happening at the same time on juno/stable. I was only referring to backing out a pin of testtools - which is needed because with single-version-tempest we can't pin any of tempests dependencies in just stable, we have to have the pins be consistent across all versions tested by tempest (with the current install strategy). -Rob You are right, I accidently folded two issues into 1. However, I do not understand how we can resolve this issue the way you have outlined without introducing a new minimum version on unittest2, which was not previously a requirement on stable/*. This surely has the same effect that I outlined? Thanks -- Kind Regards, Dave Wa;ler ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 16 November 2014 09:38, Dave Walker em...@daviey.com wrote: On 15 November 2014 20:23, Robert Collins robe...@robertcollins.net wrote: On 16 November 2014 09:03, Dave Walker em...@daviey.com wrote: On 15 November 2014 19:51, Robert Collins robe...@robertcollins.net wrote: It probably needs to be backed out of stable/icehouse. The issue is that we were installing unittest2 via distro packages *and* testtools new dependency on unittest2 did not express a minimum version. We're just about to issue 1.2.1 which will have such a minimum version. And for the record, this was released on saturday, not friday :). -Rob We've discussed this on IRC, but I fail to see how this is an appropriate fix for stable/* . This would mean introducing new minima to stable branches, which for stable branches is totally inappropriate. This causes the effect of both distros and deployers requiring a higher version which they have not planned for. If we pin oslo.messaging (which is what we started agreeing in Paris), this problems goes away. Huh? I think you're working a different bug, no? The testtools thing is what I thought this thread was about :) The oslo.messaging/middleware thing is separate but both are happening at the same time on juno/stable. I was only referring to backing out a pin of testtools - which is needed because with single-version-tempest we can't pin any of tempests dependencies in just stable, we have to have the pins be consistent across all versions tested by tempest (with the current install strategy). -Rob You are right, I accidently folded two issues into 1. However, I do not understand how we can resolve this issue the way you have outlined without introducing a new minimum version on unittest2, which was not previously a requirement on stable/*. This surely has the same effect that I outlined? But stable MUST permit new requirements, or tempest cannot change ever, since it must match the versions of the oldest release we're grenading with master tempest. So saying 'stable tests can never change requirements' is a non-starter, unless we change the way we're installing tempest there, and if we do that the unittest stuff is only applicable to tempest and thus irrelevant to the stable branches. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 2014-11-15 20:38:02 + (+), Dave Walker wrote: You are right, I accidently folded two issues into 1. However, I do not understand how we can resolve this issue the way you have outlined without introducing a new minimum version on unittest2, which was not previously a requirement on stable/*. This surely has the same effect that I outlined? You only need a new unittest2 if you're using a new testtools. The argument that we're introducing a newer requirement there is somewhat circular. If you're installing with distro packages of testtools and unittest2 then presumably your distro has pre-selected versions of them which are known to interoperate? -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 15 November 2014 21:22, Jeremy Stanley fu...@yuggoth.org wrote: On 2014-11-15 20:38:02 + (+), Dave Walker wrote: You are right, I accidently folded two issues into 1. However, I do not understand how we can resolve this issue the way you have outlined without introducing a new minimum version on unittest2, which was not previously a requirement on stable/*. This surely has the same effect that I outlined? You only need a new unittest2 if you're using a new testtools. The argument that we're introducing a newer requirement there is somewhat circular. If you're installing with distro packages of testtools and unittest2 then presumably your distro has pre-selected versions of them which are known to interoperate? -- Jeremy Stanley Ah, Good Point. I (wrongly?) assumed we were looking to put a minimum version of unittest2 in requirements. Which would cause this undesired behaviour. However, that doesn't need to be the case. I assume with this approach we WILL put an upperbound on unittest2 in stable/* requirements? If so - my point is mute. Pah. -- Kind Regards, Dave Walker ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 16 November 2014 09:06, Robert Collins robe...@robertcollins.net wrote: On 16 November 2014 03:25, Sean Dague s...@dague.net wrote: Testtools 1.2.0 release apparently broke subunit.run discover --list which breaks the way that tempest calls the test chain. No tempest runs have passed since it's release. ... I think everyone is aware that releases have some risk, and doing them cavalierly would be bad. But running with stale dependencies isn't going to be part of the test matrix upstream, since the entire project goal is to fold all its learning into upstream: as things move upstream we have to depend on newer releases of those components (via things like unittest2, importlib2, traceback2 etc etc). We did find a further issue, which was due to the use of setUpClass in tempest (a thing that testtools has never supported per se - its always been a happy accident that it worked). I've hopefully fixed that in 1.3.0 and we're babysitting tempest now to see. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
