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.
Bases: nova.db.base.Base
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.
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.
Tasks to be run at a periodic interval.
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.
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.
Bases: type
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.
Pass data back to the scheduler.
Called at a periodic interval. And also called via rpc soon after the start of the scheduler.
Remember these capabilities to send on next periodic update.
Decorator to indicate that a method is a periodic task.
This decorator can be used in two ways:
- Without arguments '@periodic_task‘, this will be run on every cycle of the periodic scheduler.
- With arguments: @periodic_task(spacing=N [, run_immediately=[True|False]]) this will be run on approximately every N seconds. If this number is negative the periodic task will be disabled. If the run_immediately argument is provided and has a value of ‘True’, the first run of the task will be shortly after task scheduler starts. If run_immediately is omitted or set to ‘False’, the first time the task runs will be approximately N seconds after the task scheduler starts.