This spec will expose the vendor passthru methods needed to let external services get, set, and commit changes to the BIOS settings. This spec will assume that the external service knows exactly what it is doing with the specific hardware it will manage, and it will not attempt to standardize, normalize, or simplify the exposed settings in any way beyond some minimal convenience measures and what is needed to map between XML and JSON.
Tuning a server for a particular workload and power consumption profile involves many different parameters to be tweaked, several of which must be tuned at the level of the system firmware. On Dell systems, doing that out-of-band involves talking to the DRAC to have it make changes on your behalf.
To expose these changes, I propose to add 4 vendor passthrough methods to the drac driver:
- get_bios_config - Gather the current BIOS configuration of the system from the drac and return it. This will return a JSON structure that contains the current BIOS configuration of the system. It has no parameters.
- set_bios_config - Queue up changes to the BIOS configuration for later committal. This will accept the same JSON data structure that get_bios_config returns. It will raise an exception if any of the changed settings does not validate as a proper change, if you try to change a readonly setting, or if the changes cannot be queued up in the DRAC for some other reason.
- commit_bios_config - Commit a set of queued up BIOS configuration changes, and schedules a system reboot if is needed to commit the changes.
- abandon_bios_config - Abandon a set of queued up BIOS configuration changes.
For this spec, only changes that can be made though the DCIM Bios and Boot Management Profile will be considered, although there are many other BIOS and hardware parameters that can be changed by the DRAC.
Create a common BIOS interface which most vendors will agree to. This is a longer term solution which should replace or drive this implementation in the future.
Four new API calls:
None for now. If this spec gets generalized to other drivers, we will need to figure out what (if any) capabilities should be exposed to Nova.
It is quite possible to render a system unbootable through this API, as it allows you to enable and disable a wide variety of hardware and mess with the boot order indiscriminately.
None expected, and there should be no stability guarantee for this API.
User documentation should mention this vendor passthrough API.