Open Stack

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 <mordred at inaugust.com> 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
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>


-- 
Sean Dague
http://dague.net