iPXE in ironic is implicitly bound to DHCP backed of neutron

[Pavlo Shchelokovskyy]

When setting DHCP options for ports in case of iPXE, ironic sets those in a format suitable for dnsmasq [0] when dhcp provider is set to 'neutron'.

By doing so ironic implicitly depends on the actual DHCP backed of neutron, that might be other than dnsmasq.

In particular, we have run into problems with OpenContrail + networking-contrail core neutron plugin. OpenContrail does not understand (and seems can not be configured to understand) the 'ipxe' tag that ironic sets to be consumed by dnsmasq, which leads to iPXE boot failure. The problem can be solved by making a copy of 'neutron' entrypoint and naming it something else, so that a different code path is taken, but that's clearly a hack, as ironic is still talking to Neutron (which in this case is just a proxy for OpenContrail SDN).

We should not differentiate between 'neutron' or not-'neutron' dhcp providers for iPXE in ironic, and always simply set the feature tag 175, letting any backend deal with it as they might see fit.

[0] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/common/pxe_utils.py#n317

[Pavlo Shchelokovskyy (pshchelo)]

Just to note, even when fixed, ironic+neutron+contrail will still have a problem of PXE->iPXE chainloading not working, but at least pure iPXE starts to work.

[Pavlo Shchelokovskyy (pshchelo)]

the patch proposed here

https://review.openstack.org/#/c/493527/

[OpenStack Infra (hudson-openstack)]

Change abandoned by Riccardo Pittau (<email address hidden>) on branch: master
Review: https://review.opendev.org/493527
Reason: obsolete

[Julia Kreger (juliaashleykreger)]

This is no longer true. A dnsmasq interface was added, and ironic now generally sets/sends/uses option numbers. We also have OVN dhcp support working, albeit with Neutron doing option translation.

The base issue is the ipxe logic being required, which the server has to be aware of to support.

But operators are also able to choose based upon their state, it is just iPXE is never going to be a viable option if the DHCP server cannot be configured to convey the necessary configuration across, so if it is conntrail, and only PXE is possible, then there is also not much the project can realistically do given the constraints of iPXE.