An Ironic deployment will be composed of the following components:
An admin-only RESTful API service, by which privileged users, such as cloud operators and other services within the cloud control plane, may interact with the managed bare metal servers.
A Conductor service, which does the bulk of the work. Functionality is exposed via the API service. The Conductor and API services communicate via RPC.
A Database and DB API for storing the state of the Conductor and Drivers.
A Deployment Ramdisk or Deployment Agent, which provide control over the hardware which is not available remotely to the Conductor. A ramdisk should be built which contains one of these agents, eg. with diskimage-builder. This ramdisk can be booted on-demand.
Note
The agent is never run inside a tenant instance.
The internal driver API provides a consistent interface between the Conductor service and the driver implementations. A driver is defined by a hardware type deriving from the AbstractHardwareType class, defining supported hardware interfaces. See Enabling drivers and hardware types for a more detailed explanation. See Pluggable Drivers for an explanation on how to write new hardware types and interfaces.
Drivers may run their own periodic tasks, i.e. actions run repeatedly after a certain amount of time. Such a task is created by using the periodic decorator on an interface method. For example
from futurist import periodics
class FakePower(base.PowerInterface):
@periodics.periodic(spacing=42)
def task(self, manager, context):
pass # do something
Here the spacing
argument is a period in seconds for a given periodic task.
For example ‘spacing=5’ means every 5 seconds.
Each Conductor registers itself in the database upon start-up, and periodically updates the timestamp of its record. Contained within this registration is a list of the drivers which this Conductor instance supports. This allows all services to maintain a consistent view of which Conductors and which drivers are available at all times.
Based on their respective driver, all nodes are mapped across the set of available Conductors using a consistent hashing algorithm. Node-specific tasks are dispatched from the API tier to the appropriate conductor using conductor-specific RPC channels. As Conductor instances join or leave the cluster, nodes may be remapped to different Conductors, thus triggering various driver actions such as take-over or clean-up.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.