Boot from a Ramdisk¶
https://storyboard.openstack.org/#!/story/1753842
While Ironic, by its very operational nature supports booting from a ramdisk, we do not empower or enable operators who wish to utilize instances that boot from ramdisks.
In the use cases desired, these are often ephemeral instances, with no actual back-end storage. That being said, we of course can’t forget cleaning and other mechanisms that help provide improved value for Ironic in a deployment.
Most of these cases are where an operator is sufficiently knowledgeable to construct a ramdisk and kernel image that can be explicitly booted from RAM. Such cases are common in High Performance Computing environments where instances may need to be quickly deployed, or are functionally disk-less in order to remove a point of failure.
Problem description¶
Operators desire fully ephemeral instances that essentially operate in RAM only. This allows compute-local disks to be dedicated to ephemeral storage, or to be omitted from the machine entirely.
Large scale cluster computing practices have long used prepared kernel/ramdisk images in order to help facilitate the stand-up and operation of their environments.
Ironic has _some_ of the support required. We do something somewhat similar with boot from volume, and if we ever support RBD booting, we would functionally require this exact feature. What delineates this from the Boot from Volume iPXE chain loading scenarios and virtual media based booting from a remote volume, is that Boot from Volume scenarios are ultimately reliant upon back-end block storage, which is not always needed or desired for all cases.
Proposed change¶
We propose to build a ramdisk
deploy interface built upon our
existing ramdisk code and facilities. This would allow us to have a
jump start on working functionality and help us better identify where
refactoring must be required.
The ramdisk
deployment driver interface would be an opt-in interface
which focuses on supporting ramdisk booting cases.
The ramdisk
deployment driver would also loop in the agent interface
classes, in order to minimize complexity and allow for cleaning workflow
and related code to remain in one location.
Mechanism wise, if the ramdisk
deployment interface is set:
The instance can boot based upon any provided instance
kernel
andramdisk
as part of the requested “glance” image to be deployed. Effectively any image contents would be ignored.The instance
boot_option
will be ignored by the ramdisk interface, and will be explicitly set toramdisk
. If otherwise set, the interface logs a warning.The same
kernel
andramdisk
parameters that are used for a “glance” image based deployment could be re-used to contain a URL.In the future, ironic should consider extending the accepted URL format to include
nfs://${server_ip}{$path}{$file}
, which would enable direct boot to NFS hosted kernel and ramdisk. This would not consist ofnfsroot
scenarios. This document does not require that is performed, but the Boot from Volume specification does explicitly state that could be a scenario implemented.An additional consideration could also be to support direct specification of a path to chain-load to.
Users must explicitly allow TFTP and/or HTTP iPXE endpoint access for booting the baremetal nodes. Typically deployments do not allow tenant networks to access to these endpoints.
Configuration drives would be ignored by ironic, and users would be advised to make use of the metadata service. Deployments with a configuration drive will explicitly result in an warning being logged by the conductor.
Operators who directly deploy nodes using ironic may need to pass additional kernel command line arguments to the node being “deployed” via a ramdisk. In this case, a
/instance_info/ramdisk_kernel_arguments
field will be accepted to allow those operators to pass information to the instance.
Building this functionality would allow us to also quickly adapt the
support to enable Ceph RBD based booting as well as ramdisk booting
to an NFS share serving as the root device. Both are features some
operators have expressed desire for. Ceph RBD support would need to
be in the underlying pxe
boot interface, as the ramdisk interface
overlays the pxe
interface. Support for Ceph RBD or NFS based
booting, from volume target
information, would be a future
enhancement.
Alternatives¶
We could consider building logic to handle and support this into the standard deployment workflow, however given this is a sufficient and specialized use case, that it might be completely unnecessary as it would not be used in most cases.
Data model impact¶
None.
State Machine Impact¶
None. Deployment would consist of setting the boot configuration and then powering on the network node.
REST API impact¶
None
Client (CLI) impact¶
“ironic” CLI¶
None
“openstack baremetal” CLI¶
None
RPC API impact¶
None
Driver API impact¶
None
Nova driver impact¶
None
Ramdisk impact¶
None
Security impact¶
No additional security impact is expected aside from a deployment scenario being able to be setup by an operator where it may be necessary to keep the deployed kernel/ramdisk potentially for an elongated period of time.
Ironic already does this with instances that are netboot.
Other end user impact¶
Operators which choose to use this feature may wish to put in place specialized network controls to facilitate the machines network booting.
Each deployment and case will be different, and without post-implementation information, we will be unable to determine if there is a standard that can be derived.
Scalability impact¶
No scalability impact anticipated.
Performance Impact¶
No substantial performance impact anticipated, although if the feature gains popularity… takeover naturally takes longer.
Other deployer impact¶
None
Developer impact¶
None
Implementation¶
Assignee(s)¶
- Primary assignee:
Julia Kreger (TheJulia)
- Other contributors:
None
Work Items¶
Create deploy interface
Create tempest test for said ramdisk deploy interface.
Create user documentation.
Dependencies¶
Testing¶
This seems like a feature that could be easily tested via a tempest scenario if the driver is available. No additional testing should be required.
Upgrades and Backwards Compatibility¶
None
Documentation Impact¶
Documentation will need to be updated to support this effort.
References¶
None