背景
自研1880 RAID卡YX1断供，需要紧急适配YX4颗粒的1880 RAID；同时RAID FW固件版本由1.x更新至2.x，固件升级带来的影响就是启动盘规格的变更，1.x版本支持1个启动盘配置，2.x版本支持5个启动盘配置。因此，需要支持动态批量配置启动盘。
关联ISSUE
https://gitcode.com/openUBMC/storage/issues/295
整体方案
在资源协作接口 bmc.kepler.Systems.Storage.Controller 下进行如下变更：
- 新增属性：
SupportedBootDeviceCount，标识当前RAID卡固件版本支持的最大启动盘数量 - 变更方法：
SetBootDevices，支持可配置的启动盘设置
详细描述
评审点1：变更属性
| 变更类型 | 属性名称 | 签名 | 只读 | 变化通知 | 属性描述 | 访问权限 | 属性来源 | 持久化类型 | 变更影响 |
|---|---|---|---|---|---|---|---|---|---|
| 新增 | SupportedBootDeviceCount | u | True | False | 表示RAID卡支持的启动盘数量 | Read: ReadOnly | 根据RAID卡TypeId和固件版本动态计算 | 不持久化 | 无影响 |
评审点2：变更方法
方案一：方法不变更，北向多次调用
核心思路：保持 SetBootDevices(ss) 接口不变，SupportedBootDeviceCount 属性告知客户端当前固件支持的最大启动盘数量，北向接口根据该值多次调用 SetBootDevices 方法完成多盘配置。
优点：
- D-Bus签名
(ss)不变，所有现有调用方mapping配置无需任何改动
缺点：
- 配置5个启动盘需要3次RPC往返，增加网络开销和延迟
- 部分成功部分失败时，北向需要处理中间状态
方案二：变更SetBootDevices方法，入参改为可变数组
核心思路：将 SetBootDevices 方法签名从 (ss) 变更为 (as)，支持传入N个启动盘，按顺序表示启动盘优先级。
| 变更类型 | 方法名称 | 请求签名 | 请求参数描述 | 响应签名 | 响应参数描述 | 方法描述 | 访问权限 | 变更影响 |
|---|---|---|---|---|---|---|---|---|
| 变更 | SetBootDevices | as | BootDevices: 启动盘设备数组，数组元素为逻辑盘或物理硬盘的设备名。数组长度范围为1~SupportedBootDeviceCount，超出范围返回错误 | 无 | 无 | 批量设置启动盘，支持一次配置多个启动盘。数组中的启动设备按顺序表示优先级 | BasicSetting | 原有接口的调用方式失效 |
优点：
- 未来固件版本支持更多启动盘时，可以轻松实现扩展
缺点：
- 接口签名变更涉及链路全层级修改
方案三：新增独立方法，老接口保留不变
核心思路：保持 SetBootDevices(ss) 接口不变，新增 SetDynamicBootDevices(as) 方法专门面向多启动盘动态批量设置。北向接口直接使用新接口。
| 变更类型 | 方法名称 | 请求签名 | 请求参数描述 | 响应签名 | 响应参数描述 | 方法描述 | 访问权限 | 变更影响 |
|---|---|---|---|---|---|---|---|---|
| 不变 | SetBootDevices | ss | PriorityDriveName:主启动盘设备 SecondaryDriveName:副启动盘设备 |
无 | 无 | 按照主副启动盘设备进行设置，且单独设置一个启动盘设备时副启动盘设备需要配置为‘None’ | BasicSetting | 无影响 |
| 新增 | SetBootDevicesV2 | as | BootDevices: 启动盘设备数组，数组元素为逻辑盘或物理硬盘的设备名。数组长度最大为可支持的启动盘数量 | 无 | 无 | 批量设置启动盘，设备按数组顺序表示优先级 | BasicSetting | 无影响 |
优点：
- 不影响现有接口，现有所有调用方无需任何改动
缺点：
- 同一业务功能（设置启动盘）存在两个接口，接口职责有重叠
评审结论
1.同意在bmc.kepler.Systems.Storage.Controller接口下新增SupportedBootDeviceCount接口，表示raid卡固件支持的最大启动盘数量
2.同意方案三，在bmc.kepler.Systems.Storage.Controller接口下新增SetBootDevicesV2方法，用于批量设置启动盘