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 hold the main function for independent services, for example.
On Fri, May 2, 2014 at 11:05 AM, Paul Michali (pcm) <[email protected]> wrote: > 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) > neutron/agent/linux/dhcp.py: raise SystemExit(msg) > neutron/db/migration/cli.py: raise SystemExit(_('You must provide a > revision or relative delta')) > neutron/openstack/common/service.py:class SignalExit(SystemExit): > neutron/openstack/common/service.py: except SystemExit as exc: > neutron/openstack/common/service.py: except SystemExit as exc: > neutron/plugins/ibm/agent/sdnve_neutron_agent.py: raise > SystemExit(1) > neutron/plugins/ibm/agent/sdnve_neutron_agent.py: raise SystemExit(1) > neutron/plugins/ml2/managers.py: raise SystemExit(msg) > neutron/plugins/mlnx/agent/eswitch_neutron_agent.py: raise > SystemExit(1) > neutron/plugins/mlnx/agent/utils.py: raise SystemExit(msg) > neutron/plugins/mlnx/mlnx_plugin.py: raise SystemExit(1) > neutron/plugins/mlnx/mlnx_plugin.py: raise SystemExit(1) > neutron/plugins/mlnx/mlnx_plugin.py: raise SystemExit(1) > neutron/plugins/nec/nec_router.py: raise SystemExit(1) > neutron/plugins/nec/nec_router.py: raise SystemExit(1) > neutron/plugins/ofagent/agent/ofa_neutron_agent.py: raise > SystemExit(1) > neutron/plugins/ofagent/agent/ofa_neutron_agent.py: raise > SystemExit(1) > neutron/plugins/ofagent/agent/ofa_neutron_agent.py: raise > SystemExit(1) > neutron/plugins/ofagent/agent/ofa_neutron_agent.py: raise > SystemExit(1) > neutron/plugins/ofagent/agent/ofa_neutron_agent.py: raise > SystemExit(1) > neutron/plugins/ofagent/agent/ofa_neutron_agent.py: raise > SystemExit(1) > neutron/plugins/openvswitch/agent/ovs_neutron_agent.py: raise > SystemExit(1) > neutron/services/loadbalancer/agent/agent_manager.py: raise > SystemExit(msg % driver) > neutron/services/loadbalancer/agent/agent_manager.py: raise > SystemExit(msg % driver_name) > neutron/services/loadbalancer/plugin.py: raise SystemExit(msg) > neutron/services/metering/agents/metering_agent.py: raise > SystemExit(_('A metering driver must be specified')) > neutron/services/metering/drivers/iptables/iptables_driver.py: > raise SystemExit(_('An interface driver must be specified')) > neutron/services/service_base.py: raise SystemExit(msg) > neutron/services/vpn/device_drivers/cisco_ipsec.py: raise > SystemExit(_('No Cisco CSR configurations found in: %s') % > > bin/neutron-rootwrap-xen-dom0: sys.exit(RC_NOCOMMAND) > bin/neutron-rootwrap-xen-dom0: sys.exit(RC_BADCONFIG) > bin/neutron-rootwrap-xen-dom0: sys.exit(RC_BADCONFIG) > bin/neutron-rootwrap-xen-dom0: sys.exit(RC_BADCONFIG) > bin/neutron-rootwrap-xen-dom0: sys.exit(RC_UNAUTHORIZED) > bin/neutron-rootwrap-xen-dom0: sys.exit(RC_XENAPI_ERROR) > bin/quantum-rootwrap-xen-dom0: sys.exit(RC_NOCOMMAND) > bin/quantum-rootwrap-xen-dom0: sys.exit(RC_BADCONFIG) > bin/quantum-rootwrap-xen-dom0: sys.exit(RC_BADCONFIG) > bin/quantum-rootwrap-xen-dom0: sys.exit(RC_BADCONFIG) > bin/quantum-rootwrap-xen-dom0: sys.exit(RC_UNAUTHORIZED) > bin/quantum-rootwrap-xen-dom0: sys.exit(RC_XENAPI_ERROR) > neutron/agent/linux/daemon.py: sys.exit(1) > neutron/agent/linux/daemon.py: sys.exit(0) > neutron/agent/linux/daemon.py: sys.exit(1) > neutron/agent/linux/daemon.py: sys.exit(0) > neutron/agent/linux/daemon.py: sys.exit(1) > neutron/agent/linux/dhcp.py: sys.exit() > neutron/openstack/common/lockutils.py: sys.exit(main(sys.argv)) > neutron/openstack/common/rpc/amqp.py: # just before doing a > sys.exit(), so cleanup() only happens once and > neutron/openstack/common/service.py: sys.exit(1) > neutron/openstack/common/systemd.py: sys.exit(retval) > neutron/plugins/bigswitch/agent/restproxy_agent.py: sys.exit(0) > neutron/plugins/linuxbridge/agent/linuxbridge_neutron_agent.py: > sys.exit(1) > neutron/plugins/linuxbridge/agent/linuxbridge_neutron_agent.py: sys.exit(0) > neutron/plugins/linuxbridge/lb_neutron_plugin.py: sys.exit(1) > neutron/plugins/linuxbridge/lb_neutron_plugin.py: sys.exit(1) > neutron/plugins/ml2/drivers/type_vlan.py: sys.exit(1) > neutron/plugins/mlnx/agent/eswitch_neutron_agent.py: sys.exit(1) > neutron/plugins/mlnx/agent/eswitch_neutron_agent.py: sys.exit(1) > neutron/plugins/mlnx/agent/eswitch_neutron_agent.py: sys.exit(0) > neutron/plugins/mlnx/mlnx_plugin.py: sys.exit(1) > neutron/plugins/mlnx/mlnx_plugin.py: sys.exit(1) > neutron/plugins/openvswitch/agent/ovs_neutron_agent.py: > sys.exit(1) > neutron/plugins/openvswitch/agent/ovs_neutron_agent.py: sys.exit(1) > neutron/plugins/openvswitch/agent/ovs_neutron_agent.py: sys.exit(1) > neutron/plugins/openvswitch/agent/ovs_neutron_agent.py: sys.exit(0) > neutron/plugins/openvswitch/ovs_neutron_plugin.py: sys.exit(1) > neutron/plugins/openvswitch/ovs_neutron_plugin.py: sys.exit(1) > neutron/plugins/openvswitch/ovs_neutron_plugin.py: sys.exit(1) > neutron/plugins/openvswitch/ovs_neutron_plugin.py: sys.exit(1) > neutron/plugins/ryu/agent/ryu_neutron_agent.py: sys.exit(1) > neutron/plugins/ryu/agent/ryu_neutron_agent.py: sys.exit(0) > neutron/plugins/vmware/check_nsx_config.py: sys.exit(1) > neutron/plugins/vmware/check_nsx_config.py: sys.exit(1) > neutron/plugins/vmware/check_nsx_config.py: sys.exit(10) > neutron/plugins/vmware/check_nsx_config.py: sys.exit(12) > neutron/server/__init__.py: sys.exit(_("ERROR: Unable to find > configuration file via the default" > neutron/server/__init__.py: sys.exit(_("ERROR: %s") % e) > neutron/wsgi.py: sys.exit(1) > tools/check_i18n.py: sys.exit(1) > tools/check_i18n.py: sys.exit(check_i18n(input_path, > tools/check_i18n.py: sys.exit(error) > tools/install_venv_common.py: sys.exit(1) > > Questions are: > > Are the usages appropriate? > Should we be consistent and use sys.exit or SystemExit everywhere (or doesn’t > it matter)? > > Regards, > > PCM (Paul Michali) > > MAIL …..…. [email protected] > IRC ……..… pcm_ (irc.freenode.com) > TW ………... @pmichali > GPG Key … 4525ECC253E31A83 > Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83 > > > > On May 2, 2014, at 10:28 AM, Doug Hellmann <[email protected]> > wrote: > >> 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 libraries don't >> throw those exceptions). Libraries should define meaningful >> exceptions, subclassed from Exception, which the main application can >> log before deciding whether to exit, retry, pick another driver, or >> whatever. >> >> On Fri, May 2, 2014 at 6:24 AM, Paul Michali (pcm) <[email protected]> wrote: >>> On May 1, 2014, at 1:23 PM, Yuriy Taraday <[email protected]> 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 sys.exit() call? >>> Should we be consistent in our use? >>> >>> openstack@devstack-32:/opt/stack/neutron$ git grep sys.exit | wc -l >>> 56 >>> openstack@devstack-32:/opt/stack/neutron$ git grep SystemExit | wc -l >>> 57 >>> >>> >>> Regards, >>> >>> PCM (Paul Michali) >>> >>> MAIL …..…. [email protected] >>> IRC ……..… pcm_ (irc.freenode.com) >>> TW ………... @pmichali >>> GPG Key … 4525ECC253E31A83 >>> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83 >>> >>> >>>> >>>> -- >>>> >>>> Kind regards, Yuriy. >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> [email protected] >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
