DRAC vendor passthru for BIOS settings management¶
https://blueprints.launchpad.net/ironic/+spec/drac-bios-mgmt
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.
Problem description¶
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.
Proposed change¶
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 thatget_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.
Alternatives¶
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.
Data model impact¶
None.
REST API impact¶
Four new API calls:
get_bios_config
- a GET method. Takes no args, returns a blob of JSON that encapsulates the BIOS configuration parameters of the system.set_bios_config
- a POST method. Takes a blob of JSON that has the same format and settings returned by get_bios_config. Returns the following status codes:200 if the set of proposed new parameters passed validation and was accepted for further processing.
204 if the set of proposed new parameters passed validation, but did not actually change the BIOS configuration.
409 if the set of proposed new parameters contains a parameter that cannot be set to the requested value, either because the parameter is read-only or the proposed new parameter is not valid.
403 if there are already proposed changes in the process of being committed.
commit_bios_config
- a POST method. Takes no args, commits the changes made byset_bios_config
calls and schedules a system reboot to apply the changes if needed. Returns the following status codes:202 if a commit job was created, and the system requires a reboot.
200 if the settings were committed without needing a reboot.
204 if there were no settings that needed to be committed.
403 if there are already proposed changes in the process of being committed.
abandon_bios_config
- a POST method. Takes no arguments, and abandons any changes made byset_bios_config
calls that have not been committed by acommit_bios_config
job. Returns the following status codes200 if the proposed changes were successfully dequeued.
204 if there were no proposed changes to dequeue
403 if the proposed changes are already in the process of being committed.
RPC API impact¶
None
Driver API impact¶
None
Nova driver impact¶
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.
Security impact¶
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.
Other end user impact¶
None
Scalability impact¶
None
Performance Impact¶
None.
Other deployer impact¶
None
Developer impact¶
None
Implementation¶
Assignee(s)¶
- Primary assignee:
victor-lowther
Work Items¶
Create and implement DracVendorPassthruBios class
Dependencies¶
This feature depends on the python bindings of the OpenWSMAN library which we already use for the rest of the DRAC driver.
This feature requires 11th or higher generations of Dell PowerEdge servers.
Testing¶
Unit tests
3rd-party CI: I will try to implement it in parallel with implementing this driver, provided I can source sufficient internal resources and appropriate network connectivity.
Upgrades and Backwards Compatibility¶
None expected, and there should be no stability guarantee for this API.
Documentation Impact¶
User documentation should mention this vendor passthrough API.