openstack/ironic
Code Issues Proposed changes
ironic/doc/source/dev/architecture.rst
Devananda van der Veen 676a157f42 More doc updates. 
Create doc/source/dev/ directory, and add several files that got
accidentaly ignored because they were under doc/source/api/.

Also move some files from doc/source into doc/source/dev to clean up the
base doc dir.

Change-Id: Ief9777216db82ec3be32b7a73e2d268a3a973ef8
2013-05-29 16:20:58 -07:00

3.5 KiB
Raw Blame History

System Architecture

High Level description

An Ironic deployment will be composed of the following components:

  • A RESTful API service, by which operators and other services may interact with the managed bare metal servers.

  • A Manager service, which does the bulk of the work. Functionality is exposed via the API service. The Manager and API services communicate via RPC.

  • A Database and DB API for storing the state of the Manager and Drivers.

  • One or more Deployment Agents, which provide local control over the hardware which is not available remotely to the Manager. 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 Manager service and the driver implementations. There are two types of drivers:

  • ControlDrivers manage the hardware, performing functions such as power on/off, toggle boot device, etc.
  • DeployDrivers handle the task of booting a temporary ramdisk, formatting drives, and putting a persistent image onto the hardware.
  • Driver implementations are loaded and instantiated via entrypoints when the Manager service starts. Each Node record stored in the database indicates which drivers should manage it. When a task is started on that node, information about the node and task is passed to the corresponding driver. In this way, heterogeneous hardware deployments can be managed by a single Manager service.

In addition to the two types of drivers, there are three categories of driver functionality: core, common, and vendor:

  • Core functionality represents the minimal API for that driver type, eg. power on/off for a ControlDriver.
  • Common functionality represents an extended but supported API, and any driver which implements it must be consistent with all other driver implementations of that functionality. For example, if a driver supports enumerating PCI devices, it must return that list as well-structured JSON. In this case, Ironic may validate the API input's structure, but will pass it unaltered to the driver. This ensures compatibility for common features across drivers.
  • Vendor functionality allows an excemption to the API contract when a vendor wishes to expose unique functionality provided by their hardware and is unable to do so within the core or common APIs. In this case, Ironic will neither store nor introspect the messages passed between the API and the driver.

Default Drivers

The default drivers, suitable for most deployments will be the IPMIPowerDriver and the PXEDeployDriver.

Additionally, for test environments that do not have IPMI (eg., when mocking a deployment using virtual machines), an SSHPowerDriver is also supplied.