Follow-up ramdisk specification

Follow-up to review feedback on the boot from ramdisk
specification[1].

[1]: https://review.openstack.org/#/c/576717/

Change-Id: Ib19c11e6acdc9367ea4af7f69801409a0f850ae4
This commit is contained in:
Julia Kreger 2018-07-24 12:11:32 -07:00
parent f47b735a0c
commit 9bd23a67e4
1 changed files with 9 additions and 6 deletions

View File

@ -39,9 +39,9 @@ Problem description
similar with boot from volume, and if we ever support RBD booting, similar with boot from volume, and if we ever support RBD booting,
we would functionally require this exact feature. What delineates we would functionally require this exact feature. What delineates
this from the Boot from Volume iPXE chain loading scenarios and this from the Boot from Volume iPXE chain loading scenarios and
virtual media based booting from a remote volume, is that these virtual media based booting from a remote volume, is that Boot
are ultimately reliant upon back-end block storage, which is from Volume scenarios are ultimately reliant upon back-end block
not always needed or desired for all cases. storage, which is not always needed or desired for all cases.
Proposed change Proposed change
=============== ===============
@ -67,6 +67,7 @@ Mechanism wise, if the ``ramdisk`` deployment interface is set:
* The instance ``boot_option`` will be ignored by the * The instance ``boot_option`` will be ignored by the
ramdisk interface, and will be explicitly set to ``ramdisk``. ramdisk interface, and will be explicitly set to ``ramdisk``.
If otherwise set, the interface logs a warning.
* The same ``kernel`` and ``ramdisk`` parameters that are used * The same ``kernel`` and ``ramdisk`` parameters that are used
for a "glance" image based deployment could be re-used to contain for a "glance" image based deployment could be re-used to contain
@ -85,10 +86,12 @@ Mechanism wise, if the ``ramdisk`` deployment interface is set:
* Users must explicitly allow TFTP and/or HTTP iPXE endpoint access for * Users must explicitly allow TFTP and/or HTTP iPXE endpoint access for
booting the baremetal nodes. Typically deployments do not allow tenant booting the baremetal nodes. Typically deployments do not allow tenant
networks are not permitted access to these endpoints. networks to access to these endpoints.
* Configuration drives would be ignored by ironic, and users would be * Configuration drives would be ignored by ironic, and users would be
advised to make use of the metadata service. 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 * Operators who directly deploy nodes using ironic may need to pass
additional kernel command line arguments to the node being "deployed" additional kernel command line arguments to the node being "deployed"
@ -103,7 +106,7 @@ operators have expressed desire for. Ceph RBD support would need to
be in the underlying ``pxe`` boot interface, as the ramdisk interface be in the underlying ``pxe`` boot interface, as the ramdisk interface
overlays the ``pxe`` interface. Support for Ceph RBD or NFS based overlays the ``pxe`` interface. Support for Ceph RBD or NFS based
booting, from ``volume target`` information, would be a future booting, from ``volume target`` information, would be a future
enhanement. enhancement.
Alternatives Alternatives
------------ ------------