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 Launcher

Bases: object

Launch one or more services and wait for them to complete.

Launcher.launch_server(server)

Load and start the given server.

Parameters:server – The server you would like to start.
Returns:None
static Launcher.run_server(server)

Start and wait for a server to finish.

Parameters:service – Server to run and wait for.
Returns:None
Launcher.stop()

Stop all services which are currently running.

Returns:None
Launcher.wait()

Waits until all services have been stopped, and then returns.

Returns:None
class ProcessLauncher

Bases: object

ProcessLauncher.launch_server(server, workers=1)
ProcessLauncher.wait()

Loop waiting on children to die and respawning as necessary

class ServerWrapper(server, workers)

Bases: object

class Service(host, binary, topic, manager, report_interval=None, periodic_interval=None, periodic_fuzzy_delay=None, *args, **kwargs)

Bases: object

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 it state to the database services table.

classmethod Service.create(host=None, binary=None, topic=None, manager=None, report_interval=None, periodic_interval=None, periodic_fuzzy_delay=None)

Instantiates class and passes back application object.

Parameters:
  • host – defaults to FLAGS.host
  • binary – defaults to basename of executable
  • topic – defaults to bin_name - ‘nova-‘ part
  • manager – defaults to FLAGS.<topic>_manager
  • report_interval – defaults to FLAGS.report_interval
  • periodic_interval – defaults to FLAGS.periodic_interval
  • periodic_fuzzy_delay – defaults to FLAGS.periodic_fuzzy_delay
Service.kill()

Destroy the service object in the datastore.

Service.periodic_tasks(raise_on_error=False)

Tasks to be run at a periodic interval.

Service.report_state()

Update the state of this service in the datastore.

Service.start()
Service.stop()
Service.wait()
class ServiceLauncher

Bases: nova.service.Launcher

ServiceLauncher.wait()
exception SignalExit(signo, exccode=1)

Bases: exceptions.SystemExit

class WSGIService(name, loader=None)

Bases: object

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

WSGIService.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
WSGIService.stop()

Stop serving this API.

Returns:None
WSGIService.wait()

Wait for the service to stop serving this API.

Returns:None
serve(server, workers=None)
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 Manager(host=None, db_driver=None)

Bases: nova.db.base.Base

Manager.create_rpc_dispatcher()

Get the rpc dispatcher for this manager.

If a manager would like to set an rpc API version, or support more than one class as the target of rpc messages, override this method.

Manager.init_host()

Handle initialization if this is a standalone service.

Child classes should override this method.

Manager.load_plugins()
Manager.periodic_tasks(context, raise_on_error=False)

Tasks to be run at a periodic interval.

Manager.service_config(context)
Manager.service_version(context)
class ManagerMeta(names, bases, dict_)

Bases: type

class SchedulerDependentManager(host=None, db_driver=None, service_name='undefined')

Bases: nova.manager.Manager

Periodically send capability updates to the Scheduler services.

Services that need to update the Scheduler of their capabilities should derive from this class. Otherwise they can derive from manager.Manager directly. Updates are only sent after update_service_capabilities is called with non-None values.

SchedulerDependentManager.load_plugins()
SchedulerDependentManager.update_service_capabilities(capabilities)

Remember these capabilities to send on next periodic update.

periodic_task(*args, **kwargs)

Decorator to indicate that a method is a periodic task.

This decorator can be used in two ways:

  1. Without arguments '@periodic_task‘, this will be run on every tick of the periodic scheduler.
  2. With arguments: @periodic_task(ticks_between_runs=N [, run_immediately=[True|False]]) this will be run on every N ticks of the periodic scheduler. If the run_immediately argument is provided and has a value of ‘True’, the first run of the task will be shortly after the task scheduler starts. If run_immediately is omitted or set to ‘False’, the first time the task runs will be after N ticks of the scheduler.

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 minimize touching the database, although it is currently acceptable for implementation specific data. This may be reconsidered at some point.

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.

Table Of Contents

Previous topic

Continuous Integration with Jenkins

Next topic

The Database Layer

This Page