|
|
| (One intermediate revision by one other user not shown) |
| Line 1: |
Line 1: |
| − | ==Motivation== | + | ==What is the Ironic Python Agent?== |
| − | At the moment, Ironic uses exactly the same deployment ramdisk as the Nova baremetal driver does. The current deploy model exposes a hard drive via iSCSI. The conductor driver then mounts this volume and writes an OS image to it.
| + | * The agent is a small python application that is embedded in a ramdisk. |
| | + | * During deployment or cleaning, a node boots the ramdisk. |
| | + | * The agent inside then exposes a REST API that Ironic uses to interact with the agent. |
| | + | * The API calls pluggable HardwareManagers to interact with the machine. |
| | | | |
| − | We believe that a deployment ramdisk should be able to do more than just expose an iSCSI volume. This ramdisk should have direct access to the hardware, and be able to:
| + | ==Current Status== |
| − | * Erase disks
| + | The ironic-python-agent is the only supported deploy mechanism for Ironic, as the old bash ramdisk was deprecated during Mitaka cycle. |
| − | * Partition disks
| |
| − | * Install bootloaders
| |
| − | * Install an OS image
| |
| − | * Update firmware
| |
| − | * Configure RAID
| |
| − | * And more...
| |
| | | | |
| − | | + | ==More Information== |
| − | Ironic-python-agent allows this functionality to be exposed to Ironic.
| + | For more information, please view ironic-python-agent documentation at http://docs.openstack.org/developer/ironic-python-agent/. |
| − | | |
| − | ==What is it?== | |
| − | * The agent is a small python application that is meant to be embedded in a ramdisk.
| |
| − | * The target machine boots this ramdisk, which starts the agent process.
| |
| − | * The agent then exposes a REST API that Ironic uses to interact with the agent.
| |
| − | * The API calls pluggable backends to interact with the machine.
| |
| − | | |
| − | ==Architecture==
| |
| − | The REST API will expose a set of fine-grained commands, such as "wipe disk" and "write image".
| |
| − | The REST API will also expose an endpoint to send a list of commands to be run asynchronously.
| |
| − | The agent will register as being on a given node, and get that node's UUID, on startup, by POSTing to the Ironic API
| |
| − | The agent will heartbeat to Ironic on a given interval.
| |
| − | All functionality, with the exception of the heartbeater and API, should be fully pluggable.
| |
| − | | |
| − | [https://www.lucidchart.com/publicSegments/view/532335f8-edc4-40c2-804e-11060a009433/image.pdf Full Ironic system architecture when using the agent.]
| |
| − | | |
| − | ==Pluggable Backends==
| |
| − | Preliminary list of backends available:
| |
| − | * Hardware (can handle both inventory and manipulation)
| |
| − | * Provisioning (bootloader/imaging/configdrive)
| |
| − | :* This could maybe be split into separate drivers, but is not yet necessary.
| |
| − | * Workflows - there are two pieces to this:
| |
| − | :* "Canned" workflows: A single endpoint that runs multiple tasks, defined by the driver. Example: a "deploy" endpoint.
| |
| − | :* Arbitrary workflows: A single endpoint that runs an arbitrary list of multiple tasks.
| |
| − | | |
| − | ==Agent driver==
| |
| − | | |
| − | The Ironic conductor will run a driver corresponding to this agent. This driver will live in the Ironic tree as an official driver. This driver may eventually be merged into Ironic's PXE driver - it will depend how much is common between the two.
| |
The ironic-python-agent is the only supported deploy mechanism for Ironic, as the old bash ramdisk was deprecated during Mitaka cycle.
