Dmitry Tantsur 152f45c993 Switch contributor documentation to hardware types

Also write a bit more meaningful documentation on writing drivers with
helpful links to move forward.

Change-Id: Id76705efabaf93a76a1370bc2e1d998622e82ac9
Partial-Bug: #1690185

2018-02-14 14:40:38 -08:00

3.2 KiB

Raw Blame History

System Architecture

High Level description

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.

Drivers

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 /install/enabling-drivers for a more detailed explanation. See drivers for an explanation on how to write new hardware types and interfaces.

Driver-Specific Periodic Tasks

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.

Message Routing

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.

3.2 KiB Raw Blame History