Open Stack

So, I tried to reproduce, but I actually see the same results with both of these. However, they both show the issue I was hitting, namely, I got no information on where the failure was located:

root at devstack-32:/opt/stack/neutron# tox -e py27 -v -- neutron.tests.unit.pcm.test_pcm
using tox.ini: /opt/stack/neutron/tox.ini
using tox-1.6.1 from /usr/local/lib/python2.7/dist-packages/tox/__init__.pyc
py27 reusing: /opt/stack/neutron/.tox/py27
  /opt/stack/neutron$ /opt/stack/neutron/.tox/py27/bin/python /opt/stack/neutron/setup.py --name
py27 develop-inst-nodeps: /opt/stack/neutron
  /opt/stack/neutron$ /opt/stack/neutron/.tox/py27/bin/pip install -U -e /opt/stack/neutron --no-deps >/opt/stack/neutron/.tox/py27/log/py27-163.log
py27 runtests: commands[0] | python -m neutron.openstack.common.lockutils python setup.py testr --slowest --testr-args=neutron.tests.unit.pcm.test_pcm
  /opt/stack/neutron$ /opt/stack/neutron/.tox/py27/bin/python -m neutron.openstack.common.lockutils python setup.py testr --slowest --testr-args=neutron.tests.unit.pcm.test_pcm
running testr
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1 ${PYTHON:-python} -m subunit.run discover -t ./ ${OS_TEST_PATH:-./neutron/tests/unit} --list
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1 ${PYTHON:-python} -m subunit.run discover -t ./ ${OS_TEST_PATH:-./neutron/tests/unit}  --load-list /tmp/tmpkYugPE
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1 ${PYTHON:-python} -m subunit.run discover -t ./ ${OS_TEST_PATH:-./neutron/tests/unit}  --load-list /tmp/tmpPoDsN3
ouch
======================================================================
FAIL: process-returncode
tags: worker-1
----------------------------------------------------------------------
Binary content:
  traceback (test/plain; charset="utf8")
======================================================================
FAIL: process-returncode
tags: worker-0
----------------------------------------------------------------------
Binary content:
  traceback (test/plain; charset="utf8")
Ran 4 (+4) tests in 0.348s
FAILED (id=150, failures=2 (+2))
error: testr failed (1)
ERROR: InvocationError: '/opt/stack/neutron/.tox/py27/bin/python -m neutron.openstack.common.lockutils python setup.py testr --slowest --testr-args=neutron.tests.unit.pcm.test_pcm'
______________________________________________________________________________________________ summary _______________________________________________________________________________________________
ERROR:   py27: commands failed

It looks like there was some traceback, but it doesn’t show it. Any ideas how to get around this, as it makes it hard to troubleshoot these types of failures?

Here is the code:

# Copyright 2014 Cisco Systems, Inc.  All rights reserved.
#
#    Licensed under the Apache License, Version 2.0 (the "License"); you may
#    not use this file except in compliance with the License. You may obtain
#    a copy of the License at
#
#         http://www.apache.org/licenses/LICENSE-2.0
#
#    Unless required by applicable law or agreed to in writing, software
#    distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
#    WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
#    License for the specific language governing permissions and limitations
#    under the License.
#
# @author: Paul Michali, Cisco Systems, Inc.

import sys

from neutron.tests import base

def using_sys_exit():
    sys.exit(1)

def using_SystemExit():
    raise SystemExit("ouch")


class TestSystemExit(base.BaseTestCase):

    def test_using_sys_exit(self):
        self.assertIsNone(using_sys_exit())

    def test_using_SystemExit(self):
        self.assertIsNone(using_SystemExit())


Regards,


PCM (Paul Michali)

MAIL …..…. pcm at cisco.com<mailto:pcm at cisco.com>
IRC ……..… pcm_ (irc.freenode.com<http://irc.freenode.com>)
TW ………... @pmichali
GPG Key … 4525ECC253E31A83
Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83



On May 1, 2014, at 1:23 PM, Yuriy Taraday <yorik.sar at gmail.com<mailto:yorik.sar at gmail.com>> wrote:

On Thu, May 1, 2014 at 8:17 PM, Salvatore Orlando <sorlando at nicira.com<mailto:sorlando at nicira.com>> wrote:
The patch you've been looking at just changes the way in which SystemExit is used, it does not replace it with sys.exit.
In my experience sys.exit was causing unit test threads to interrupt abruptly, whereas SystemExit was being caught by the test runner and handled.

According to https://docs.python.org/2.7/library/sys.html#sys.exit , sys.exit(n) is an equivalent for raise SystemExit(n), it can be confirmed in the source code here: http://hg.python.org/cpython/file/2.7/Python/sysmodule.c#l206
If there's any difference in behavior it seems to be the problem of test runner. For example, it can mock sys.exit somehow.

I find therefore a bit strange that you're reporting what appears to be the opposite behaviour.

Maybe if you could share the code you're working on we can have a look at it and see what's going on.

I'd suggest finding out what's the difference in both of your cases.

Coming back to topic, I'd prefer using standard library call because it can be mocked for testing.

--

Kind regards, Yuriy.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140501/2504b3a0/attachment.html>