Is this a new feature, an enhancement, or a change to existing functionality?
Enhancement
How would you describe the priority of this feature request
Medium
Please provide a clear description of problem this feature solves
During new hardware onboarding, MAT/bmc-mock can currently pass with a modeled Redfish fixture that does not fully reflect the raw BMC scrape state for critical provisioning surfaces.
In particular, we should add validation that new hardware fixtures preserve the real Redfish behavior for setup paths used by provisioning, including:
- BIOS attributes needed to enable/disable network boot protocols
- BootOptions present before setup
- BootOptions expected after setup/reboot
- Boot order programmability by MAC/device path
- SecureBoot resource shape and writable fields
- TPM enablement attributes
- Option ROM controls needed for network boot targets to appear
- Infinite boot controls, where required by the platform
- OEM lockdown / host-interface resources used by setup-status polling
- Whether unsupported BIOS attributes are rejected rather than silently accepted by bmc-mock
Today, a fixture can model the desired final state, such as HTTP BootOptions already being present, while the real BMC scrape may only expose PXE BootOptions and no Redfish-accessible knob to enable HTTP boot. MAT can then validate the simulated NICo control flow without proving that the real BMC can be programmatically moved into the required provisioning-ready state.
This should reduce the chance that newly onboarded hardware passes MAT while still missing firmware/BMC capabilities required for real fleet provisioning.
Feature Description
As a NICo developer onboarding new hardware, I want MAT/bmc-mock tests to validate provisioning-critical Redfish surfaces against the raw BMC scrape, so that simulated onboarding does not pass when the real BMC cannot be programmatically moved into the required boot-ready state.
When a new hardware fixture is added, the test suite shall verify that the modeled Redfish fixture preserves the raw scrape behavior for provisioning-critical surfaces such as BIOS attributes, BootOptions, boot override support, SecureBoot, TPM, Option ROM controls, infinite boot controls, and OEM setup-status resources.
When a platform requires HTTP/network boot, the test suite shall verify that either the required BootOptions already exist or that Redfish exposes a writable BIOS/OEM path that can materialize them after setup/reboot.
Describe your ideal solution
Add a hardware onboarding readiness check around MAT/bmc-mock fixtures:
- Add a raw-scrape conformance check for critical Redfish surfaces used by provisioning.
- Add a hardware readiness assertion: either required HTTP/network BootOptions already exist, or Redfish exposes a writable BIOS/OEM path to materialize them.
- Add a strict bmc-mock mode that rejects BIOS PATCH attrs not present in the modeled BIOS registry.
- Extend hardware onboarding tests to assert
machine_setup_status / boot-readiness, not only hardware classification and report generation.
- Consider golden tests comparing raw scrape data to bmc-mock output for BIOS attrs, BootOptions, SecureBoot, boot override support, TPM, Option ROM controls, and OEM setup-status resources.
Describe any alternatives you have considered
Relying on existing MAT runs and bmc-explorer classification tests is not enough because those can validate the simulated control flow without proving that the raw BMC surface exposes the required setup controls.
Manual scrape review helps, but it is easy to miss gaps and does not provide lasting regression coverage once the fixture is added.
Additional context
Potentially affected modules:
crates/machine-a-tron
crates/bmc-mock
crates/bmc-explorer
crates/site-explorer
- hardware onboarding documentation under
docs/development
This is related in spirit to simulator fidelity issues such as #3363 and #3430, but focused specifically on Redfish fixture fidelity and provisioning-readiness validation for new hardware onboarding.
Code of Conduct
Is this a new feature, an enhancement, or a change to existing functionality?
Enhancement
How would you describe the priority of this feature request
Medium
Please provide a clear description of problem this feature solves
During new hardware onboarding, MAT/bmc-mock can currently pass with a modeled Redfish fixture that does not fully reflect the raw BMC scrape state for critical provisioning surfaces.
In particular, we should add validation that new hardware fixtures preserve the real Redfish behavior for setup paths used by provisioning, including:
Today, a fixture can model the desired final state, such as HTTP BootOptions already being present, while the real BMC scrape may only expose PXE BootOptions and no Redfish-accessible knob to enable HTTP boot. MAT can then validate the simulated NICo control flow without proving that the real BMC can be programmatically moved into the required provisioning-ready state.
This should reduce the chance that newly onboarded hardware passes MAT while still missing firmware/BMC capabilities required for real fleet provisioning.
Feature Description
As a NICo developer onboarding new hardware, I want MAT/bmc-mock tests to validate provisioning-critical Redfish surfaces against the raw BMC scrape, so that simulated onboarding does not pass when the real BMC cannot be programmatically moved into the required boot-ready state.
When a new hardware fixture is added, the test suite shall verify that the modeled Redfish fixture preserves the raw scrape behavior for provisioning-critical surfaces such as BIOS attributes, BootOptions, boot override support, SecureBoot, TPM, Option ROM controls, infinite boot controls, and OEM setup-status resources.
When a platform requires HTTP/network boot, the test suite shall verify that either the required BootOptions already exist or that Redfish exposes a writable BIOS/OEM path that can materialize them after setup/reboot.
Describe your ideal solution
Add a hardware onboarding readiness check around MAT/bmc-mock fixtures:
machine_setup_status/ boot-readiness, not only hardware classification and report generation.Describe any alternatives you have considered
Relying on existing MAT runs and bmc-explorer classification tests is not enough because those can validate the simulated control flow without proving that the raw BMC surface exposes the required setup controls.
Manual scrape review helps, but it is easy to miss gaps and does not provide lasting regression coverage once the fixture is added.
Additional context
Potentially affected modules:
crates/machine-a-troncrates/bmc-mockcrates/bmc-explorercrates/site-explorerdocs/developmentThis is related in spirit to simulator fidelity issues such as #3363 and #3430, but focused specifically on Redfish fixture fidelity and provisioning-readiness validation for new hardware onboarding.
Code of Conduct