Redfish VirtualMedia never gets BOOTIF kernel parameter

[s3rj1k]

What steps did you take and what happened:
Create typical BMH with redfish-virtualmedia BMC and wait for Inspection to start

What did you expect to happen:
Inside IPA OS I expect to see BOOTIF kernel parameter in /proc/cmdline with value that comes from spec.bootMACAddress of BMH

Anything else you would like to add:
Rationale why BOOTIF is also important in virtualmedia case:

Consider a host that has a lot of NICs in, running dhclient against all of them takes time and some even might freeze, given that we already enforce spec.bootMACAddress to be set in all cases it makes sense to pass that data into virtualmedia ISO so that some specific script inside IPA would consume it and try to get IP on that NIC.

It does only covers the case when connectivity to Ironic is provided via PXE network so this should be optional on IPA side but facility to get this info should still be provided by BMO.

Environment:

• Baremetal Operator version: v0.11.0
• Environment (metal3-dev-env or other): custom setup with CAPM3 (version is irrelevant to issue)

/kind bug

[s3rj1k]

Slack discussion for reference: https://kubernetes.slack.com/archives/CHD49TLE7/p1759358215753559

[s3rj1k]

And related Ironic "bug": https://bugs.launchpad.net/ironic/+bug/2126644

[Rozzii]

I will wait with the triaging a little bit , first let's see how the Ironic discussion goes.

[s3rj1k]

https://review.opendev.org/c/openstack/ironic/+/964168

[Rozzii]

I think the request:

"As an ironic operator, I don't want to be forced for the ramdisk to DHCP all my interfaces, I only want a specific interface DHCP'ed and I want to do that in my ramdisk using BOOTIF kernel parameter."

is totally valid but I think the implementation https://review.opendev.org/c/openstack/ironic/+/964168 involves to many unrelated subsystems. In the end the user would like to have "BOOTIF=" in the kernel cmdline params which is fine but instead of mixing pxe control logic with the vmedia control logic I think it would be cleaner if the user would just add the "BOOTIF=" value to the kernel_append_params field of the specific node's driver_info.

If the goal is to provide a general approach to optimize what interfaces are "DHCP'd" then IMO dhcpless scenarios has to be taken into consideration especially when it comes to redfish vmedia where injecting the "BOOTIF=" would be not necessary .

When it comes to Metal3 there is already a feature in progress that would allow setting kernel_append_params on a per BMH/ironic node bases.
Refs:

• propose additional node specific pre-provisioning kernel args metal3-docs#552
• ✨ introduce preprovisioningKernelParams to BMH #2576

[s3rj1k]

As an operator I don't want to set another field manually in BMH spec to make things happen.

So if this is going to be solved by purely BMO, introduced feature should pickup bootMAC value and populate kernel_append_params by itself.

[Rozzii]

Okay, I will just copy here what I mentioned on the Ironic gerrit:

The WIP feature I have linked will improve on the existing preprovisioningImage functionality so I think that it will be simpler to add a boolean optional spec field to the BMH to auto populate the kernel params with BOOTIF= using the functionality of metal3-io/metal3-docs#552.

So IMO we can solve this on BMO side alone. And I agree with you that it makes sense from consumer perspective to not ask for the bootMacAddress in two separate places, reather we would need a spec option to allow BMO to automatically generate the BOOTIF= and append it to the kernel params.

That said, if Ironic community would like to have a dedicated API field to allow this behavior we can support that too, I don't think we need dedicated option for bootMacadress equivalent on Ironic side but from Metal3 perspective there is no harm in that either.

BTW any of the kernel parameter customization features work only if IPA is supplied as kernel+initramfs which is a natural case for PXE booting but not for VMEDIA or UEFI http boot.
Pre built IPA ISO can't receive the customizations as Ironic can't inject it right now. That is one reason folks use the custom controllers to build IPA images on the fly and provide the related configs as preprovisioningImage CRs. With custom controllers user can build or re-package the IPA ISO on the fly.

[Rozzii]

/triage accepted
/kind feature
As discussed on Ironic issue tracker, this is not a bug in Vmedia use-cases but a feature.

The fundamental request to optimize dhcp usage makes sense, we just need to sort out where do we need to change code.