Please have the customer set the boot_interface to "ipxe". The boot interfaces were split upstream to allow multiarchitecture and specific configuration differences, where most deployers prefer iPXE, for it they really ought to be using the specific boot_interface for it as opposed to the general pxe interface which would be for aspects such as network booting using other bootloaders such as GRUB.

It does appear that using the ilo hardware type will default their experience to the "pxe" interface, which means there are a few different smaller bugs there and just setting the boot_interface to "ipxe" should resolve the issue for now.

I did some checking in puppet-ironic as well as ironic itself, and the default value being loaded for the uefi_pxe_bootfile_name parameter. It actually comes from the upstream project when not set.

Explicitly setting an override in puppet-ironic to the default may not be possible as it would introduce additional unexpected behavior, which also changes again in future releases. The customer can change it locally by asserting configuration override parameter "pxe/uefi_pxe_bootfile_name" to "snponly.efi".

As noted above, the default switches to "bootx64.efi" for use with GRUB network booting, which would be an unintended, yet different user experience. Overall this is rooted back in the creation of the node and the overall "default_boot_interface", or lack their of. The user could just change the boot interface of the node to "ipxe".

For furhter context, boot_interface selection occurs one of two ways. Via an explicit "default_boot_interface" parameter, which is asserted as the default. This could be passed in as an override parameter setting the default to "ipxe". If no default is defined, then is a union of the hardware type's supported interfaces and the enabled boot interfaces is used to identify the first value preferred by the hardware type. This is how the "ilo" hardware type ends up with this issue.


So to rehash, three options exist:
1) Just change the node's "boot_interface" to ipxe before inspecting/deploying.
2) Setup an override parameter for the puppet configuration to set a "pxe/uefi_pxe_bootfile_name" parameter to "snponly.efi". They will of course need to re-setup the undercloud to do this.
3) Setup an override parameter for the puppet configuration to set a "default_boot_interface" parameter to "ipxe". Again, they will need ot change their deployed undercloud configuration for his to be effective.

I'll leave this open to allow the larger team to review it upon our next bug triage session. I have also uploaded a change to fix the overall boot_interface order for the ilo hardware type, but I'm unsure if we will be able to backport that change at this time.

I think the overall problem is (as Yamato pointed out in his initial analysis) that we hard-code [pxe] uefi_pxe_bootfile_name to ipxe.efi.
 https://github.com/openstack/tripleo-heat-templates/blob/stable/train/deployment/ironic/ironic-conductor-container-puppet.yaml#L368

puppet-ironic provides the ironic::pxe class, which is commonly used by the other classes related to pxe/ipxe setup.
Current tht set the bootfile parameter of this base class according to the IronicIPXEUefiSnpOnly parameter here,
but the above override is preventing that common definition from being used.
 https://github.com/openstack/tripleo-heat-templates/blob/stable/train/deployment/ironic/ironic-conductor-container-puppet.yaml#L468

I feel like the good solution here is to remove that hardcode, so that we use snponly.efi/ipxe.efi according to IronicIPXEUefiSnpOnly
in that pxe driver setting. The current default is a kind of broken and does not work.

I agree it is a problem, but the node should not be using the "pxe" interface to begin with. It should be using the "ipxe" boot_interface.

I agree we ought to remove the hard code, unfortunately my plate is also full at the moment.

Thank you for your help, Julia and Takashi.

> 1) Just change the node's "boot_interface" to ipxe before inspecting/deploying.

I asked the customer to run the following command,
  $ openstack baremetal node set <node> --boot-interface ipxe
but it failed due to the following error.
  boot interface implementation '<ironic.drivers.modules.ipxe.iPXEBoot object at 0x7f6784e886a0>' is not supported by hardware type IloHardware. (HTTP 400)

`ilo` driver only supports `ilo-pxe` boot interface, so I think this is expected behavior.
~~~
(undercloud) [stack@undercloud ~]$ openstack baremetal driver show ilo -c enabled_boot_interfaces
+-------------------------+---------+
| Field                   | Value   |
+-------------------------+---------+
| enabled_boot_interfaces | ilo-pxe |
+-------------------------+---------+
~~~

> 2) Setup an override parameter for the puppet configuration to set a "pxe/uefi_pxe_bootfile_name" parameter to "snponly.efi". They will of course need to re-setup the undercloud to do this.

I asked the customer to set "pxe/uefi_pxe_bootfile_name" parameter to "snponly.efi", and the customer reported us that the overcloud deployment succeeded.
Thank you for your help, again!

Sorry, I forgot the ilo hardware type actually has their own boot interface alias which I've forgotten about, ilo-ipxe.

Which is also on the interface load order, but would need to be in the configuration as well. Obviously, in this case, thye are hard coded to ilo-pxe, and don't have ilo-ipxe enabled at all.

Interestingly enough, afaik, this is not a specific configuration we supply an example of. I guess they are just supplying a number of specific settings and one of them happens to just be the ilo-pxe boot interface on it's own.

I'm glad ot hear that just setting the template parameter worked for them.

Fix has landed upstream in Zed, targeting for 18.0