Running into a situation where, when we flip a DPU from DPU mode into NIC mode, the NetworkDeviceFunction goes Disabled (which I believe is expected, since the DPU is now just a plain NIC), but the problem is, as part of it becoming Disabled, it looks like (at least in the case of Dell) DRAC doesn't probe the NIC for a MAC address, meaning that machine_setup fails, because our MAC -> interface ID resolver flows fail, so machine setup flows fail.
Additionally, the HTTP boot device configs get reset back to the default, so when we DO flip a DPU from DPU mode to NIC mode, we get:
- Default boot device set (the integrated NIC)
- The DPU effectively disappears as an option, since it has no MAC being reported (it's even empty in
System.EthernetInterface[].MACAddress and in NetworkAdatpers.
HOWEVER, if you explicitly set the Interface ID (Interface Partition ID) for the MAC-less interface as a boot device:
- It's accepted.
- It appears to re-probe the interface, and re-populates the MAC address.
- It UEFI HTTP boots just fine.
I was hoping I could approach it by re-enabling the NetworkDevicePartition. But unfortunately, when it's in NIC mode, the only option presented is Disabled, and it's set to Disabled, so that's not an option.
The only other thing I can think of right now is making it so machine_setup (and similar calls) take an enum that allows you to provide a ::Mac (like we do now) or the direct ::InterfaceId to boot from. The former looks up the Interface ID anyway, so when provided an Interface ID directly, we just use it.
And in our case, we have the Interface ID already, so we know exactly what to "set it back to.", and if we don't have it, we'll attempt to use the MAC address, and if we can't figure anything out, then it's a total Redfish bug that we can't really work around.
Running into a situation where, when we flip a DPU from DPU mode into NIC mode, the
NetworkDeviceFunctiongoesDisabled(which I believe is expected, since the DPU is now just a plain NIC), but the problem is, as part of it becomingDisabled, it looks like (at least in the case of Dell) DRAC doesn't probe the NIC for a MAC address, meaning thatmachine_setupfails, because our MAC -> interface ID resolver flows fail, so machine setup flows fail.Additionally, the HTTP boot device configs get reset back to the default, so when we DO flip a DPU from DPU mode to NIC mode, we get:
System.EthernetInterface[].MACAddressand inNetworkAdatpers.HOWEVER, if you explicitly set the Interface ID (Interface Partition ID) for the MAC-less interface as a boot device:
I was hoping I could approach it by re-enabling the
NetworkDevicePartition. But unfortunately, when it's in NIC mode, the only option presented isDisabled, and it's set toDisabled,so that's not an option.The only other thing I can think of right now is making it so
machine_setup(and similar calls) take an enum that allows you to provide a::Mac(like we do now) or the direct::InterfaceIdto boot from. The former looks up the Interface ID anyway, so when provided an Interface ID directly, we just use it.And in our case, we have the Interface ID already, so we know exactly what to "set it back to.", and if we don't have it, we'll attempt to use the MAC address, and if we can't figure anything out, then it's a total Redfish bug that we can't really work around.