diff options
author | Devananda van der Veen <devananda.vdv@gmail.com> | 2013-05-23 08:42:10 -0700 |
---|---|---|
committer | Devananda van der Veen <devananda.vdv@gmail.com> | 2013-05-23 09:08:02 -0700 |
commit | e177c381bda562b2705e6c85125b70f0d71d8806 (patch) | |
tree | 3768a909c1f75d0f7e29b40edca1be7aaf333a34 /README.rst | |
parent | 4c3574bb5553255cac391d1fc59ca5546eda1ced (diff) | |
download | ironic-e177c381bda562b2705e6c85125b70f0d71d8806.tar.gz |
More updates to the README.
- Correct driver type names.
- Add more description about driver loading and implementation.
Change-Id: I145c7a64b9e5def4e103309ee3c9fe45204ae5d6
Diffstat (limited to 'README.rst')
-rw-r--r-- | README.rst | 47 |
1 files changed, 28 insertions, 19 deletions
diff --git a/README.rst b/README.rst index fdb8b5efb..94f0b8c01 100644 --- a/README.rst +++ b/README.rst @@ -38,29 +38,38 @@ Project Architecture 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. -- An internal **driver API** for different Manager functions. - There are currently two driver types: BMCDriver and DeploymentDriver. -- Internal drivers for each function are dynamically loaded, according to the - specific hardware being managed, such that heterogeneous hardware deployments - can be managed by a single Manager service. -- 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 +- 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. +- 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 https://github.com/stackforge/diskimage-builder, and this ramdisk can be booted on-demand. The agent is never run inside a tenant instance. -- A **Database** and a DB API for storing persistent state of the Manager and Drivers. - - -In addition to the two types of drivers, BMCDriver and DeploymentDriver, there -are three categories of driver functionality: core, common, and vendor: +- A **Database** and a DB API for storing persistent state of the Manager and + 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 + ManagerService 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 BMCDriver. + 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 |