Thanks for the exception explanation - now I understand better what is going on
there. Yuriy’s mention about looking in .testrepository gave me the needed
piece on how to find out where the failure occurred.
Regards,
PCM (Paul Michali)
MAIL …..…. p...@cisco.com
IRC ……..… pcm_
It was in init code for a device driver, which (currently, as a short term PoC
solution) reads a config file for settings of statically configured VPN
devices. If there are no devices at all, it will report the issue and the agent
will exit. In the future, will be dynamically obtaining the
On May 1, 2014, at 1:23 PM, Yuriy Taraday yorik@gmail.com wrote:
Coming back to topic, I'd prefer using standard library call because it can
be mocked for testing.
Yeah that’s probably the open question I still have. Does the community prefer
raising a SystemError exception or use the
As Robert said, libraries should not be calling sys.exit() or raising
SystemExit directly, ever.
Throwing SystemExit from a library bypasses other exception handling
cleanup code higher in the stack that is unlikely to be looking for
fatal exceptions like SystemExit (because well-behaved
Here are the calls in Neutron:
neutron/agent/l3_agent.py:raise SystemExit(msg)
neutron/agent/l3_agent.py:raise SystemExit(msg)
neutron/agent/l3_agent.py:raise SystemExit(msg)
neutron/agent/linux/dhcp.py:raise SystemExit(msg)
My guess is the rootwrap and oslo service stuff is OK, the daemon
module may be OK, but all of the plugins should be changed. That's
just a guess after a cursory review, though, and someone who knows the
neutron code better than I do will have to make the call. Some of
those plugin modules may
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.
I find therefore a bit strange
On Thu, May 1, 2014 at 8:17 PM, Salvatore Orlando sorla...@nicira.comwrote:
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
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@devstack-32:/opt/stack/neutron# tox -e py27 -v --
neutron.tests.unit.pcm.test_pcm
using
On Thu, May 1, 2014 at 10:41 PM, Paul Michali (pcm) p...@cisco.com wrote:
==
FAIL: process-returncode
tags: worker-1
--
*Binary content:*
* traceback
On Thu, 2014-05-01 at 18:41 +, Paul Michali (pcm) wrote:
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:
So, this is pretty much by design. A
Raising SystemExit *or* calling sys.exit() are poor ideas: only outer
layer code should do that. Plumbing should only be raising semantic,
normally catchable exceptions IMO.
-Rob
On 2 May 2014 07:09, Kevin L. Mitchell kevin.mitch...@rackspace.com wrote:
On Thu, 2014-05-01 at 18:41 +, Paul
Hi,
In Neutron I see SystemExit() being raised in some cases. Is this preferred
over calling sys.exit()?
I ask, because I recall having a TOX failure where all I was getting was the
return code, with no traceback or indication at all of where the failure
occurred. In that case, I changed from
13 matches
Mail list logo