From e6e4a04b109904060cdcd5abf9985224094097ae Mon Sep 17 00:00:00 2001 From: Lucas Alvares Gomes Date: Mon, 27 Apr 2015 12:46:27 +0100 Subject: [PATCH] iPXE dynamic configuration This blueprint adds support for dynamically generating iPXE configuration files when booting a node. Change-Id: I443d969638ce56beb5bc9b8484b65fdac4bc469a --- specs/liberty/ipxe-dynamic-config.rst | 215 ++++++++++++++++++++++++++ 1 file changed, 215 insertions(+) create mode 100644 specs/liberty/ipxe-dynamic-config.rst diff --git a/specs/liberty/ipxe-dynamic-config.rst b/specs/liberty/ipxe-dynamic-config.rst new file mode 100644 index 00000000..ca0e1471 --- /dev/null +++ b/specs/liberty/ipxe-dynamic-config.rst @@ -0,0 +1,215 @@ +.. + This work is licensed under a Creative Commons Attribution 3.0 Unported + License. + + http://creativecommons.org/licenses/by/3.0/legalcode + +========================== +iPXE Dynamic Configuration +========================== + +https://blueprints.launchpad.net/ironic/+spec/ipxe-dynamic-config + +This blueprint adds support for dynamically generating iPXE configuration +files when booting a node. + +Problem description +=================== + +The current iPXE support depends on configuration files to be cached on +the disk. This creates a dependency between a given ``ironic-conductor`` +and a given node (even without a conductor lock on a node) because that +``ironic-conductor`` is the only one able to boot that node. This also +makes take-over more complicated because the new ``ironic-conductor`` +will need to regenerate the iPXE configuration files for the new nodes +it's now managing and update the DHCP server accordingly. + +Proposed change +=============== + +The proposed implementation consists of creating a new ``Driver Vendor +Passthru`` method called ``ipxe_config`` that will dynamically generate +the iPXE configuration files for a given node UUID or mac address +depending on the node's provision state. + +When Neutron is used with iPXE enabled, it will configure the DHCP server +to make a request to the ``Driver Vendor Passthru`` endpoint using the +node's UUID when booting a node, e.g:: + + http://:6385/v1/drivers//vendor_passthru/ipxe_config?node_uuid= + +Ironic will then check the ``provision_state`` of the node and +generate the iPXE configuration file for that state. Say, the node +``provision_state`` is DEPLOYING, we then will return an iPXE +configuration to boot the deploy ramdisk and kernel. If the node +``provision_state`` is ACTIVE, we then return an iPXE configuration +to boot from the image ramdisk and kernel (If local boot and/or full +disk image is not specified). For an unknown ``provision_state`` we just +return an iPXE configuration file that prints out an error explaining the +problem on the node's console log and a warning message in the Ironic log. + +If an operator wants to have an external DHCP server (standalone version) +but still benefit from dynamically generated iPXE script files (instead +of using static files) it will be possible by making the same ``Driver +Vendor Passthru`` endpoint to support passing the MAC address of one of +the node's port as parameter, e.g:: + + http://:6385/v1/drivers//vendor_passthru/ipxe_config?port_address= + +When scripting iPXE allows `expanding variables +`_ so that an operator can +create a single iPXE script pointing to the Ironic API (and expanding +the ``${mac}`` variable) when configuring their external DHCP server +allowing them to have dynamically generated iPXE configuration for their +environment even when Neutron is not used. + +This work can get even more powerful when the images are set to boot from +``http`` [#]_, as then the iPXE drive won't need to save any state on +the disk. As a future work, it would be also possible to add support for +creating a ``Swift Temporary URL`` when booting images being served by +``Glance`` with a ``Swift`` storage backend. + + +Alternatives +------------ + +Continue doing what we are doing, generate the configuration files and +saving it to the disk. + +Data model impact +----------------- + +None + +State Machine Impact +-------------------- + +None + +REST API impact +--------------- + +A new ``Driver Vendor Passthru`` method called ``ipxe_config`` that +supports GET HTTP. + +Client (CLI) impact +------------------- + +None + +RPC API impact +-------------- + +Currently the RPC method for ``vendor_passthru`` and +``driver_vendor_passthru`` returns a tuple with the return value and a +boolean indicating if the method is asynchronous. We will need another +flag to indicate if the value should be returned as a static file that +will be served by the Ironic API instead of a response body message. + +Driver API impact +----------------- + +None + +Nova driver impact +------------------ + +None + +Security impact +--------------- + +The new ``Vendor Passthru`` method endpoint needs to be part of the +public API, so that iPXE can get the configuration file from without +authentication. This is the same as the methods ``heartbeat`` or +``lookup`` for the agent driver [#]_. + +Other end user impact +--------------------- + +None + +Scalability impact +------------------ + +A stateless driver can scale better since it won't depend on any +information to be saved on the local conductor. + +Performance Impact +------------------ + +None + +Other deployer impact +--------------------- + +None + +Developer impact +---------------- + +None + +Implementation +============== + +Assignee(s) +----------- + +Primary assignee: + lucasagomes + +Other contributors: + + +Work Items +---------- + +* Create the new ``ipxe_config`` method for the PXEVendorPassthru interface. + +* Change the PXE configuration options passed to the DHCP server to point + to the ``v1/drivers//vendor_passthru/ipxe_config?node_uuid=`` endpoint in + the Ironic API instead of pointing to the URL to download the boot.ipxe + script (the script won't be need anymore and will be deleted). + +* Extend the ``vendor_passthru`` and ``driver_vendor_passthru`` RPC + methods to return a flag indicating whether the return value should + be attached to the response object as a file or returned as a response + message. + +* Update the methods ``prepare_ramdisk`` and ``clean_up_ramdisk`` from + the **IPXEBoot** interface to not attempt to create or delete the iPXE + configuration files. + + +Dependencies +============ + +* `New boot interface + `_: + This spec is refactoring the boot logic out of the current Ironic + ``deploy`` drivers into a new boot interface. + + +Testing +======= + +Unittests will be added. + +Upgrades and Backwards Compatibility +==================================== + +None + +Documentation Impact +==================== + +The iPXE documentation will be updated to reflect the changes made by +this spec. + +References +========== + +.. [#] http://specs.openstack.org/openstack/ironic-specs/specs/kilo/non-glance-image-refs.html +.. [#] https://github.com/openstack/ironic/blob/master/ironic/api/config.py