To use oslo.service in a project:
Migrating to oslo.service¶
oslo.service library no longer assumes a global configuration object is
available. Instead the following functions and classes have been
changed to expect the consuming application to pass in an
When using service from oslo-incubator¶
from foo.openstack.common import service launcher = service.launch(service, workers=2)
When using oslo.service¶
from oslo_config import cfg from oslo_service import service CONF = cfg.CONF launcher = service.launch(CONF, service, workers=2)
Using oslo.service with oslo-config-generator¶
oslo.service provides several entry points to generate configuration
The options from the
eventlet_backdoormodules for the
The options from the
periodic_taskmodule for the
The options from the
wsgimodule for the
ATTENTION: The library doesn’t provide an oslo.service entry point.
$ oslo-config-generator --namespace oslo.service.service \ --namespace oslo.service.periodic_task \ --namespace oslo.service.sslutils
Launching and controlling services¶
oslo_service.service module provides tools for launching OpenStack
services and controlling their lifecycles.
A service is an instance of any class that
ServiceBase is an
abstract class that defines an interface every
service should implement.
serve as a base for constructing new services.
oslo_service.service module provides two launchers for running
oslo_service.service.ServiceLauncher- used for running one or more service in a parent process.
oslo_service.service.ProcessLauncher- forks a given number of workers in which service(s) are then started.
It is possible to initialize whatever launcher is needed and then launch a service using it.
from oslo_config import cfg from oslo_service import service CONF = cfg.CONF service_launcher = service.ServiceLauncher(CONF) service_launcher.launch_service(service.Service()) process_launcher = service.ProcessLauncher(CONF, wait_interval=1.0) process_launcher.launch_service(service.Service(), workers=2)
Or one can simply call
oslo_service.service.launch() which will
automatically pick an appropriate launcher based on a number of workers that
are passed to it (
in other case).
from oslo_config import cfg from oslo_service import service CONF = cfg.CONF launcher = service.launch(CONF, service.Service(), workers=3)
It is highly recommended to use no more than one instance of the
ProcessLauncher class per process.
oslo_service.service provides handlers for such signals as
SIGTERM is used for graceful termination of services. This can allow a
server to wait for all clients to close connections while rejecting new
incoming requests. Config option
graceful_shutdown_timeout specifies how many seconds
after receiving a
SIGTERM signal a server should continue to run, handling
the existing connections. Setting
graceful_shutdown_timeout to zero means that the server
will wait indefinitely until all remaining requests have been fully served.
To force instantaneous termination the
SIGINT signal must be sent.
The behavior on receiving
SIGHUP varies based on how the service is
configured. If the launcher uses
restart_method='reload' (the default),
then the service will reload its configuration and any threads will be
completely restarted. If
restart_method='mutate' is used, then only the
configuration options marked as mutable will be reloaded and the service
threads will not be restarted.
oslo_service.service.Launcher for more details on the
SIGHUP is not supported on Windows.
graceful_shutdown_timeout is not
supported on Windows.
Below is an example of a service with a reset method that allows reloading
logging options by sending a
from oslo_config import cfg from oslo_log import log as logging from oslo_service import service CONF = cfg.CONF LOG = logging.getLogger(__name__) class FooService(service.ServiceBase): def start(self): pass def wait(self): pass def stop(self): pass def reset(self): logging.setup(cfg.CONF, 'foo')
Processes spawned through
oslo_service.service can be profiled (function
calltrace) through the
eventlet_backdoor module. The
service must be configured with the
to enable its workers to listen on TCP ports. The user can then send the
prof() command to capture the worker process’s function calltrace.
To start profiling send the
prof()command on the process’s listening port
To stop profiling and capture pstat calltrace to a file, send the
prof()command with a file basename as an argument (
prof(basename)) to the worker process’s listening port. A stats file (in pstat format) will be generated in the temp directory with the user-provided basename with a
For example, to profile a neutron server process (which is listening on
port 8002 configured through the
$ echo "prof()" | nc localhost 8002 $ neutron net-create n1; neutron port-create --name p1 n1; $ neutron port-delete p1; neutron port-delete p1 $ echo "prof('neutron')" | nc localhost 8002
This will generate a stats file in
/tmp/neutron.prof. Stats can be printed
from the trace file as follows:
import pstats stats = pstats.Stats('/tmp/neutron.prof') stats.print_stats()