Services, Managers and Drivers

The responsibilities of Services, Managers, and Drivers, can be a bit confusing to people that are new to nova. This document attempts to outline the division of responsibilities to make understanding the system a little bit easier.

Currently, Managers and Drivers are specified by flags and loaded using utils.load_object(). This method allows for them to be implemented as singletons, classes, modules or objects. As long as the path specified by the flag leads to an object (or a callable that returns an object) that responds to getattr, it should work as a manager or driver.

The nova.service Module

Generic Node base class for all workers that run on hosts.

class nova.service.Service(host, binary, topic, manager, report_interval=None, periodic_enable=None, periodic_fuzzy_delay=None, periodic_interval_max=None, *args, **kwargs)

Bases: oslo_service.service.Service

Service object for binaries running on hosts.

A service takes a manager and enables rpc by listening to queues based on topic. It also periodically runs tasks on the manager and reports its state to the database services table.

basic_config_check()

Perform basic config checks before starting processing.

classmethod create(host=None, binary=None, topic=None, manager=None, report_interval=None, periodic_enable=None, periodic_fuzzy_delay=None, periodic_interval_max=None)

Instantiates class and passes back application object.

Parameters

  • host – defaults to CONF.host

  • binary – defaults to basename of executable

  • topic – defaults to bin_name - ‘nova-‘ part

  • manager – defaults to CONF.<topic>_manager

  • report_interval – defaults to CONF.report_interval

  • periodic_enable – defaults to CONF.periodic_enable

  • periodic_fuzzy_delay – defaults to CONF.periodic_fuzzy_delay

  • periodic_interval_max – if set, the max time to wait between runs

kill()

Destroy the service object in the datastore.

NOTE: Although this method is not used anywhere else than tests, it is convenient to have it here, so the tests might easily and in clean way stop and remove the service_ref.

periodic_tasks(raise_on_error=False)

Tasks to be run at a periodic interval.

reset()

reset the service.

start()

Start the service.

This includes starting an RPC service, initializing periodic tasks, etc.

stop()

stop the service and clean up.

class nova.service.WSGIService(name, loader=None, use_ssl=False, max_url_len=None)

Bases: oslo_service.service.Service

Provides ability to launch API from a ‘paste’ configuration.

reset()

Reset the following:

  • server greenpool size to default

  • service version cache

  • cell cache holding database transaction context managers

Returns

None

start()

Start serving this service using loaded configuration.

Also, retrieve updated port number in case ‘0’ was passed in, which indicates a random port should be used.

Returns

None

stop()

Stop serving this API.

Returns

None

wait()

Wait for the service to stop serving this API.

Returns

None

nova.service.assert_eventlet_uses_monotonic_clock()
nova.service.process_launcher()
nova.service.serve(server, workers=None)
nova.service.setup_profiler(binary, host)
nova.service.wait()

The nova.manager Module

Base Manager class.

Managers are responsible for a certain aspect of the system. It is a logical grouping of code relating to a portion of the system. In general other components should be using the manager to make changes to the components that it is responsible for.

For example, other components that need to deal with volumes in some way, should do so by calling methods on the VolumeManager instead of directly changing fields in the database. This allows us to keep all of the code relating to volumes in the same place.

We have adopted a basic strategy of Smart managers and dumb data, which means rather than attaching methods to data objects, components should call manager methods that act on the data.

Methods on managers that can be executed locally should be called directly. If a particular method must execute on a remote host, this should be done via rpc to the service that wraps the manager

Managers should be responsible for most of the db access, and non-implementation specific data. Anything implementation specific that can’t be generalized should be done by the Driver.

In general, we prefer to have one manager with multiple drivers for different implementations, but sometimes it makes sense to have multiple managers. You can think of it this way: Abstract different overall strategies at the manager level(FlatNetwork vs VlanNetwork), and different implementations at the driver level(LinuxNetDriver vs CiscoNetDriver).

Managers will often provide methods for initial setup of a host or periodic tasks to a wrapping service.

This module provides Manager, a base class for managers.

class nova.manager.Manager(host=None, service_name='undefined')

Bases: nova.db.base.Base, nova.manager.PeriodicTasks

cleanup_host()

Hook to do cleanup work when the service shuts down.

Child classes should override this method.

init_host()

Hook to do additional manager initialization when one requests the service be started. This is called before any service record is created.

Child classes should override this method.

periodic_tasks(context, raise_on_error=False)

Tasks to be run at a periodic interval.

post_start_hook()

Hook to provide the manager the ability to do additional start-up work immediately after a service creates RPC consumers and starts ‘running’.

Child classes should override this method.

pre_start_hook()

Hook to provide the manager the ability to do additional start-up work before any RPC queues/consumers are created. This is called after other initialization has succeeded and a service record is created.

Child classes should override this method.

reset()

Hook called on SIGHUP to signal the manager to re-read any dynamic configuration or do any reconfiguration tasks.

class nova.manager.ManagerMeta(names, bases, dict_)

Bases: nova.profiler.get_traced_meta.<locals>.NoopMeta, oslo_service.periodic_task._PeriodicTasksMeta

Metaclass to trace all children of a specific class.

This metaclass wraps every public method (not starting with _ or __) of the class using it. All children classes of the class using ManagerMeta will be profiled as well.

Adding this metaclass requires that the __trace_args__ attribute be added to the class we want to modify. That attribute is a dictionary with one mandatory key: “name”. “name” defines the name of the action to be traced (for example, wsgi, rpc, db).

The OSprofiler-based tracing, although, will only happen if profiler instance was initiated somewhere before in the thread, that can only happen if profiling is enabled in nova.conf and the API call to Nova API contained specific headers.

class nova.manager.PeriodicTasks

Bases: oslo_service.periodic_task.PeriodicTasks

Implementation-Specific Drivers

A manager will generally load a driver for some of its tasks. The driver is responsible for specific implementation details. Anything running shell commands on a host, or dealing with other non-python code should probably be happening in a driver.

Drivers should not touch the database as the database management is done inside nova-conductor.

It usually makes sense to define an Abstract Base Class for the specific driver (i.e. VolumeDriver), to define the methods that a different driver would need to implement.