18
18
.. _service_manager_driver:
20
Services Managers and Drivers
21
=============================
20
Services, Managers and Drivers
21
==============================
23
23
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.
25
25
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.
30
A service is a very thin wrapper around a Manager object. It exposes the manager's public methods to other components of the system via rpc. It will report state periodically to the database and is responsible for initiating any periodic tasts that need to be executed on a given host.
32
The :mod:`service` Module
33
~~~~~~~~~~~~~~~~~~~~~~~~~~~
28
The :mod:`nova.service` Module
29
------------------------------
35
31
.. automodule:: nova.service
43
Managers are responsible for a certain aspect of the sytem. 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.
45
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.
47
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.
49
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
51
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.
53
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).
55
Managers will often provide methods for initial setup of a host or periodic tasksto a wrapping service.
57
The :mod:`manager` Module
58
~~~~~~~~~~~~~~~~~~~~~~~~~~~
37
The :mod:`nova.manager` Module
38
------------------------------
60
40
.. automodule:: nova.manager
46
Implementation-Specific Drivers
47
-------------------------------
68
49
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.
added
removed
doc/source/devref/services.rst
