This blueprint adds support for exposing a configdrive image to instances deployed by Ironic.
Instances deployed by Ironic should be able to use cloud-init (or similar software) to put an end user’s data on an instance. This is possible today with Ironic by including cloud-init with the image, and pointing it at a Nova metadata service.
There are two issues with this approach:
To solve these problems, a configdrive image can take the place of the metadata service. In the VM world, this is typically handled by the hypervisor exposing a configdrive image to the VM as a volume.
In Ironic’s case, there is no hypervisor, so this image needs to be exposed to the instance in some other fashion. This could be accomplished by writing the image to a partition on the node, exposing the image via the out-of-band mechanism (e.g. a virtual floppy in HP’s iLO), or configuring the node to mount the image from a SAN. In any case, this needs to be handled by Ironic, rather than Nova. However, Nova has the data that belongs in the configdrive, as well as the code to generate the image. So, it makes sense for Nova to generate an image and pass it to Ironic.
This blueprint outlines how Ironic will handle the configdrive image that Nova provides and expose it to an instance.
Nova’s Ironic virt driver will generate a config drive image, gzip and base64 enconde it and pass to the Ironic service as part of the setting provision state call. This is discussed in more detail in this nova spec.
For that, we have to extend our API to optionally accept a config drive as part of the request BODY.
If the config drive is present, Ironic will either upload the data to Swift and update the Node’s instance_info to include the temporary URL from the upload or if swift if not configured, the config drive data will be stored directly into the Node’s instance_info field.
From there deploy drivers will will be responsible for exposing the configdrive to the instance, as well as removing the configdrive from the instance upon deletion. This cannot be coordinated by code outside of the driver, as only the driver can know when and how to take these actions.
Some mechanisms a driver may use to expose a configdrive include:
There are no clear alternatives here.
A “configdrive” key will be added to node.instance_info.
Extend the /nodes/<uuid>/provision endpoint to accept an optional configdrive parameter as part of the request BODY.
Since the config drive is only valid when spawning an instance, in the Ironic API passing the configdrive parameter will be only valid when setting the Node’s provision state to active. Passing the parameter to any other provision state should return HTTP 400 (Bad Request).
The config drive passed via the API should be passed down to the do_node_deploy RPC method.
The nova driver will need to implement the functionality to generate the configdrive image and get it to Ironic.
This is discussed in the corresponding nova spec.
This proposal involves storing end user data as an image in Swift. This may be a security concern, as this data is not encrypted at rest.
There are methods for securing this data that are out of the scope of this initial work.
Use of the configdrive would require a call to Swift (or some other object store), which will have some impact on the system, but is probably negligible.
This feature might require deploying some object store service (Swift for the reference implementation).
Developers writing drivers should implement this functionality, but it is not required, as it may not be possible for some drivers.
This change depends on the corresponding Nova spec.
A tempest test should be added that deploys a bare metal instance with a configdrive, and verifies that the configdrive is properly written to the instance.
The Ironic code will need to be deployed before enabling configdrive support in Nova.
This feature is completely optional, so it is backward compatible.
Documentation may need to be updated to indicate that a configdrive may be used with instances deployed by Ironic.