[RFE] Allow to not cache images on conductor for iPXE nodes in standalone mode

[Pavlo Shchelokovskyy]

In integrated mode, Ironic already supports skipping caching of deploy image kernel/ramdisk on the conductor node when iPXE is used (through pxe.ipxe_use_swift option) and not serving those images from per-conductor HTTP servers, in which case node boots into deploy image directly from Swift TempURLs.

It is proposed to add support for similar functionality for standalone Ironic.

As our currently preferred deploy method with agent already requires that user images are stored on a HTTP server available from inside provisioning network, iPXE-capable nodes can boot to deploy image if this is stored on the same server as well and not cache them locally.

For this it is proposed to add a config option pxe.ipxe_supported_schemes (list option, defaults to empty list for backward compatibility) that will define a common for all Ironic nodes set of URI schemes (e.g. http, https) supported by iPXE bootloader so that when deploy image kernel and ramdisk have URI of such schemes, they will not be cached on ironic-conductor host to be served by per-conductor HTTP server, but instead nodes will boot from those URIs directly.

Alternatively, to support a more heterogeneous set of nodes, instead of global config option a new node capability field of the same name (also, defaulting to an empty list for backward compatibility) can be introduced and checked against when preparing the node boot to deploy image.

This can simplify ironic-conductor deployment by not hard requiring the per-conductor HTTP server, improve performance for distributed standalone Ironic as the (static) external HTTP server can be scaled horizontally, and make the ironic-conductor service more state-less.

[Vladyslav Drok (vdrok)]

The patch seems to be here, not sure why the bug # is different - https://review.openstack.org/367321 seems pretty straight forward to me

[Ruby Loo (rloo)]

This was brought up in today's ironic meeting [1]. It needs a spec, and vdrok has a link to a spec that looks like *it*. Please do the necessary paperwork to connect that spec to this RFE if it is indeed the right spec :)

[1] starting at 17:28:41, http://eavesdrop.openstack.org/meetings/ironic/2016/ironic.2016-12-05-17.01.log.html