Atom feed of this document
 

 Conductor

The nova-conductor service enables OpenStack to function without compute nodes accessing the database. Conceptually, it implements a new layer on top of nova-compute. It should not be deployed on compute nodes, or else the security benefits of removing database access from nova-compute are negated. Just like other nova services such as nova-api or nova-scheduler, it can be scaled horizontally. You can run multiple instances of nova-conductor on different machines as needed for scaling purposes.

In the Grizzly release, the methods exposed by nova-conductor are relatively simple methods used by nova-compute to offload its database operations. Places where nova-compute previously performed database access are now talking to nova-conductor. However, we have plans in the medium to long term to move more and more of what is currently in nova-compute up to the nova-conductor layer. The compute service will start to look like a less intelligent slave service to nova-conductor. The conductor service will implement long running complex operations, ensuring forward progress and graceful error handling. This will be especially beneficial for operations that cross multiple compute nodes, such as migrations or resizes.

Table 2.31. Description of configuration options for conductor
Configuration option=Default value Description
manager=nova.cells.manager.CellsManager (StrOpt) Manager for cells
manager=nova.conductor.manager.ConductorManager (StrOpt) full class name for the Manager for conductor
migrate_max_retries=-1 (IntOpt) Number of times to retry live-migration before failing. If == -1, try until out of hosts. If == 0, only try once, no retries.
topic=cells (StrOpt) the topic cells nodes listen on
topic=conductor (StrOpt) the topic conductor nodes listen on
use_local=False (BoolOpt) Perform nova-conductor operations locally
workers=None (IntOpt) Number of workers for OpenStack Conductor service

Log a bug against this page


loading table of contents...