We were having issues getting bifrost to work correctly on our new gigabyte servers and had them look at the issue.
"Bifrost/Ironic uses Redfish' BootSourceOverrideTarget, BootSourceOverrideMode, and BootSourceOverrideEnabled properties in order to manipulate the next boot device. We were able to determine that other vendor's Redfish implementation allows these properties to be set independently, while our implementation requires these three properties to be set in the same request. From our analysis, Bifrost/Ironic's Redfish driver does not always send all three properties in the same request, thus failing node enrollment."
They have suggested we reach out to Bifrost/Ironic to "see if their software can allow for an implementation that permits all 3 properties to be sent in the same request."
Greetings,
Is there any chance we could get debug logging from this issue?
Specifically details covering the request being acted upon for the request, any stack traces, and the response from the BMC.
To answer the question, We might be able to, but we need to understand exactly what the BMC is doing in response to the existing request. Does the Gigabyte BMC just error? Does it fail to execute properly when the power is turned on?
We presently only independently change the boot mode from target and source overrides, as the mode is generally disjointed from the target/source. This is also necessary because some of the vendor's BMCs, depending on version, have entirely different behaviors and even feature sets which operate depending on boot mode. At least historically, this might have changed, but we sort of had the opposite issue in the past.
The question is if we can just send the mode when setting boot device? Or do we need to send all three options whenever changing any boot related option. i.e. We can't just change BootSourceOverr
Another thing we'll need likely know is the vendor field. If you can capture an entire /redfish/
Thanks,
-Julia