Both `BootOrder` and `BootSourceOverride` are part of the `Boot` section of the `ComputerSystem` schema. The `description` for `BootOrder` is as follows: "An array of BootOptionReference strings that represent the persistent boot order for with this computer system. Changes to the boot order typically require a system reset before they take effect. It is likely that a client finds the `@redfish.Settings` term in this resource, and if it is found, the client makes requests to change boot order settings by modifying the resource identified by the `@redfish.Settings` term."
Which of the following options are valid and recommended?
1. Both `BootOrder` and `BootSourceOverride` should be patched in the `Settings` resource.
2. Both `BootOrder` and `BootSourceOverride` should be patched in the active resource.
3. `BootOrder` should be patched in the `Settings` resource, and `BootSourceOverride` should be patched in the active resource.
In option 3, users should patch `BootOrder` in the `Settings` resource, but patch `BootSourceOverride` in the active resource. Will this potentially confuse users?
BootOrder is a glorified method to change the boot listing in the BIOS setup menu, and that I would expect to be managed under a settings resource. The reason being is the settings request needs to be staged and consumed in order for the setting to be updated in BIOS.
BootSourceOverride does not go that far. It's an override request stored in the BMC, and extracted by BIOS on each boot; it's never saved by BIOS and the request is always "active". The semantics of the property are always "this is what we'll attempt on the next boot", so putting this in a settings resource I think adds even more confusion; it could be interpreted that two reboots are required for the override to take place.
I do understand your point about potential confusion if they are not both PATCH'd in the same place, but given the mechanics of these properties, I don't see a good way to solve this.