On 07/28/2013 09:28 PM, Davanum Srinivas wrote:
Monty,
I picked up a latest run
https://jenkins.openstack.org/job/gate-grenade-devstack-vm/22236/
which lead me to
http://logs.openstack.org/51/38951/2/check/gate-grenade-devstack-vm/22236/logs/new/screen-c-vol.txt.gz
So could the problem be 38810 itself?
2013-07-29 00:46:37.562 27821 TRACE cinder.service Stderr: 'Traceback
(most recent call last):\n File "/usr/local/bin/cinder-rootwrap",
line 4, in <module>\n from pkg_resources import require;
require(\'cinder==2013.2.a78.g465eb62\')\n File
"/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2707, in
<module>\n working_set.require(__requires__)\n File
"/usr/lib/python2.7/dist-packages/pkg_resources.py", line 686, in
require\n needed = self.resolve(parse_requirements(requirements))\n
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 584,
in resolve\n raise
DistributionNotFound(req)\npkg_resources.DistributionNotFound:
jsonschema>=0.7,<3\n'
Well, it's a think regardless. Tempest is definitely downgrading
jsonschema when it hits it's requirements phase:
Downloading/unpacking jsonschema>=1.0.0,!=1.4.0,<2 (from -r
/opt/stack/new/tempest/requirements.txt (line 6))
Downloading jsonschema-1.3.0.tar.gz
Storing download in cache at
/var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fjsonschema%2Fjsonschema-1.3.0.tar.gz
Running setup.py egg_info for package jsonschema
http://logs.openstack.org/51/38951/2/check/gate-grenade-devstack-vm/22236/logs/grenade.sh.log.2013-07-29-003611
Seems weird, but I guess entrypoints now mean lots of things blow up if
we do things like this. I'm rushing through a revert on this commit now
- https://review.openstack.org/#/c/39005/ as it's low impact and we can
revisit later. Will look harder in the morning.
On Sun, Jul 28, 2013 at 8:02 PM, Monty Taylor <[email protected]> wrote:
Hey all!
There is currently an issue with which is causing a very high failure
rate in the gate. From IRC:
18:32:19 clarkb | the grenade failures seem to get very
consistent in the gate at 2013-0-27 1552UTC
18:32:27 clarkb | before that the success rate is much higher
18:34:53 clarkb | *2013-07-27
18:40:01 clarkb | https://review.openstack.org/#/c/38810/ was
the last change to pass grenade when it was semi consistently passing
18:41:31 clarkb | 38587 and 28082 seem like strong candidates
for the breakage
The working hypothesis is that since the grenade gate is assymetrical
(it consumes grizzly and trunk but only gates trunk) that a change to
grizzly went in that broke something for trunk. Obviously this is
something we want to avoid - but since this is our first time gating on
upgrade patterns in this way, it's also probably a good chance for us to
learn about the process of doing that.
In any case, although I'm sure dtroyer and sdague will take a look as
soon as they are online, it's unlikely that anything is going to land
until this is sorted- so I'm sure they'd appreciate any help from anyone
who can look in to the actual issue.
Thanks!
Monty
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Sean Dague
http://dague.net
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
