Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world

2014-11-17 Thread Robert Collins
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

2014-11-17 Thread Sean Dague
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

2014-11-17 Thread Sean Dague
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

2014-11-17 Thread Andreas Jaeger
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

2014-11-17 Thread Alan Pevec
 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

2014-11-17 Thread Sean Dague
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

2014-11-17 Thread Doug Hellmann

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

2014-11-17 Thread Robert Collins
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-16 Thread Alan Pevec
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

2014-11-16 Thread Robert Collins
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

2014-11-16 Thread Robert Collins
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

2014-11-16 Thread Nikhil Manchanda
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


Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world

2014-11-15 Thread Davanum Srinivas
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

2014-11-15 Thread Jeremy Stanley
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

2014-11-15 Thread Dave Walker
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

2014-11-15 Thread Robert Collins
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

2014-11-15 Thread Dave Walker
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

2014-11-15 Thread Jeremy Stanley
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

2014-11-15 Thread Robert Collins
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

2014-11-15 Thread Robert Collins
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

2014-11-15 Thread Dave Walker
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

2014-11-15 Thread Robert Collins
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

2014-11-15 Thread Jeremy Stanley
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

2014-11-15 Thread Dave Walker
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

2014-11-15 Thread Robert Collins
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