已开启
[需求]: rackmount CLI 支持设置8电源主备模式 #1057
yctco_zhangxuan6931创建于 9月3日
openUBMC-robot
9月3日 评论：
9月3日 评论：
9月3日 将 ZanthoxylumLeaf 设为负责人
9月3日 添加了label：sig/sig-interface
openUBMC-robot
9月3日 评论：
9月3日 评论：
欢迎来到 openUBMC 社区
Hey @zx-zzj , 感谢你对社区的贡献.
机器人使用手册
有关指令的使用，可以点击 说明文档 或 论坛 查看详情。开发人员可以在每个PR或Issue下方评论特定指令来触发机器人任务。您可以自助配置此仓库的 PR 合并规则，更多详情，请参阅机器人自助配置使用手册。
联系指引
有疑问可以联系 SIG: sig-interface ,
维护者是： @DataSculptor, @WeliveWelove, @aaronlee, @huanghan ,
优秀贡献者是： @L_Ling, @PLUS_ONE, @yelvsub .
9月3日 关联了看板：openUBMC 26.09 需求看板
openUBMC-robot
9月3日 评论：
9月3日 评论：
Issue 工作流介绍
社区的需求和缺陷的工作流状态处于纳管中。
| 类型 | 上个状态 | 下个状态 | 评论命令 | 谁可以操作 |
|---|---|---|---|---|
| 需求 | 待办的 | 已接纳 | /todo2accepted | SIG组: sig-release-management (maintainer) |
| 需求 | 已接纳 | 开发中 | /accepted2developing | 仓库成员角色: Maintainer, Committer, Contributor, Owner |
| 需求 | 开发中 | 待验收 | /developing2UAT | 仓库成员角色: Maintainer, Committer, Contributor, Owner |
| 需求 | 待验收 | 已完成 | /UAT2done | SIG组: sig-QA (maintainer,committer) |
| 需求 | 待办的 | 已挂起 | /todo2suspended | SIG组: sig-release-management (maintainer) |
| 需求 | 已挂起 | 已接纳 | /suspended2accepted | SIG组: sig-release-management (maintainer) |
| 需求 | 待办的 | 已拒绝 | /todo2rejected | SIG组: sig-release-management (maintainer) |
| 需求 | 已拒绝 | 已接纳 | /rejected2accepted | SIG组: sig-release-management (maintainer) |
9月8日 移除了负责人 ZanthoxylumLeaf
openUBMC-robot
9月8日 评论：
9月8日 评论：
9月8日 将 ZanthoxylumLeaf 设为负责人
9月8日 将 WeberChen 设为负责人，移除负责人 ZanthoxylumLeaf
9月8日 修改了issue 的描述
9月8日 移除了负责人 WeberChen
openUBMC-robot
9月8日 评论：
9月8日 评论：
9月8日 将 ZanthoxylumLeaf 设为负责人
9月8日 将 zx-zzj 设为负责人，移除负责人 ZanthoxylumLeaf
9月11日 关联了看板：openUBMC 26.12需求看板
9月11日 移除了看板：openUBMC 26.09 需求看板
9 天前 关联了pull request：feat: ipmcset支持设置8电源主备模式
11 小时前 issue状态由 待办的 改变为 已接纳
11 小时前 关闭了 issue
11 小时前 重新打开了 issue
zhaotianli
9 小时前 评论：
9 小时前 评论：
PR #1654 回顾分析: feat: ipmcset支持设置8电源主备模式
仓库: openUBMC/rackmount
分支: feat/8psu_cli → main
合并时间: 2026-11-04 20:08
AI 检视来源:
atomgit-bot（2 轮代码审查）、openubmc-ci-bot（多轮检视报告）、Richardli25（结构化深度检视）。以下对 13 条 AI 行内意见逐条追踪后续处理。
1. AI 检视意见追踪
| # | AI 发现（位置 / 摘要） | 来源 | 后续处理 | 说明 |
|---|---|---|---|---|
| 1 | _psuworkmode:21 帮助 range 忽略 device[3] 显式槽位表，与校验口径不一致 |
ci-bot | ✅ 已采纳并修复 | commit 18ef0478 修改该行，最终 get_max_psu_num() 已读取 device[3]，与校验脚本口径对齐 |
| 2 | _psuworkmode:55 槽位解析逻辑在两个脚本中重复且行为不一致 |
ci-bot | 💬 已回复说明 | 开发者回复"已修改"（10-29），解析逻辑后续收敛 |
| 3 | target.json:1146 Usage 帮助文本未同步多电源形态 |
ci-bot | ✅ 已采纳并修复 | 最终 Usage 已更新为 [active psuid ...|enabled/disabled] |
| 4 | target.json:1163 Usage 应更新为可表达多 psuid 的形式 |
atomgit-bot | ✅ 已采纳并修复 | 最终 Usage 已更新（同 #3） |
| 5 | check_psuworkmode_params_valid.lua:32 槽位集合按 1..max_num 展开、未用显式槽位表 |
atomgit-bot | ✅ 已采纳并修复 | commit 18ef0478 修改该行，最终 get_psu_slots() 支持显式槽位表并回退 1..max_num |
| 6 | check_psuworkmode_params_valid.lua:46 规格读取失败时 max_active_num=0 静默判非法、提示误导 |
atomgit-bot | ✅ 已采纳并修复 | atomgit-bot 第二轮确认"新增了规格读取失败时的显式提示"，不再重复上报 |
| 7 | get_psuworkmode_active_psu_list.lua:27 参数上限 8 多处硬编码、超限静默截断 |
atomgit-bot | ⏸ 已确认闭环（未改代码） | 第二轮仍列"存在"，最终代码保留两处 MAX_ACTIVE_PSU_ARGS=8；经检视人 resolve 关闭，评审贴遗留问题"参数数量边界已确认无问题"对应闭环 |
| 8 | check_psuworkmode_params_valid.lua:32 device[3] 分支疑似死代码（全仓无第三列消费方） |
atomgit-bot | ✅ 已采纳并修复 | commit 18ef0478 修改该行；最终 echo 与校验两侧统一支持 device[3] |
| 9 | _psuworkmode:21 帮助 range 上限未受 8 个参数上限约束 |
ci-bot | ✅ 已采纳并修复 | commit 18ef0478 修改该行，帮助与校验按同一槽位表对齐 |
| 10 | _psuworkmode:17 help 按最大槽号展示与按槽位集合校验在非连续槽位时矛盾 |
atomgit-bot | ✅ 已采纳并修复 | commit 624cc1b1 修改该行 |
| 11 | target.json:1246 Chassis 规格读取无 CallIf，可能拖累负载均衡/深度休眠路径 |
atomgit-bot | ✅ 已采纳并修复 | commit ff779d41 修改该行，经检视人确认关闭 |
| 12 | power.lua:44 以 MAX_PSU_NUM 作槽位号上界过滤，>8 槽位机型规格被整体丢弃 |
atomgit-bot | ✅ 已采纳并修复 | commit ff779d41 修改该行；power.lua 最终移出 PR 变更集，槽位解析收敛于校验脚本 |
| 13 | power.lua:37 校验槽位表依赖 DeviceSpecication 第三列，仓内无消费方 |
atomgit-bot | ✅ 已采纳并修复 | commit ff779d41 修改该行（同 #12，随 power.lua 变更一并处理） |
补充: Richardli25 结构化检视总结另提 5 条意见，其中"规格读取失败静默""device[3] 死代码/口径""上限 8 硬编码"与上表 #6/#8/#7 同主题；另两条——"device[2] 未过滤 0xFF 哨兵值"（atomgit-bot 第二轮确认已修复）、"CHANGELOG.md 未更新"（CI pre-commit 由 FAILED 转为 SUCCESS，已修复）——均已闭环。
| 指标 | 结果 |
|---|---|
| AI 行内意见总数 | 13 |
| 已采纳并修复 | 11 |
| 已回复说明 | 1 |
| 已确认闭环（未改代码） | 1 |
| 未响应 | 0 |
2. 人工检视补充
- 检视人: fumingquan、lixiaocan、changxingOpenUBMC、aaronlee
- 意见概要:
- fumingquan（11-04）: 要求补齐验证报告——"验证太简单了，设置负载均衡，设置参数超过边界等等"。开发者当日回复"已补充验证报告"，PR 描述已包含 7 电源、8 边界、超 8 报 usage、负载均衡、乱序输入、空参数共 6 类场景截图。
- lixiaocan: 对全部 13 条 AI 行内意见逐一确认并 resolve，充当 AI 意见的闭环裁决人。
- changxingOpenUBMC: 补充评审帖链接；并在评审贴中要求评审结论按规范描述清楚（不止写"评审通过"）。
- aaronlee: 最终 /lgtm + /approve，并处理 needs-issue 标签完成合入。
- 解决状态: 全部已解决。本 PR 人工检视无行内 diff_comment，人工意见集中在验证充分性与流程合规性。
3. 评审贴覆盖情况
评审贴链接：【已评审】CLI支持设置8个电源的主备模式
| 评审点 | 是否涵盖 |
|---|---|
ipmcset -d psuworkmode -v 1 [active psuid] 支持输入最多 8 个主用电源 |
✅ 已涵盖（ReqBody 扩展 value4~value9，校验支持 1~N 个 psuid 且含槽位合法性/去重，GetActivePsuList 下发 ActivePowerSuppliesList） |
回显 range 根据电源槽位号动态显示 <1-n> |
✅ 已涵盖（get_max_psu_num() 动态读取 DeviceSpecication） |
覆盖统计: 2/2。评审贴遗留问题"参数数量的边界需要进行确认和验证"已在贴内确认闭环（已确认参数数量无问题）。
4. 总结
- AI 意见闭环率 100%: 13 条行内意见无一条未响应，12 条有代码修复或"已修改"回复（92%），开发者经过 10-29、11-03 共三轮代码迭代逐项消化检视意见；atomgit-bot 第二轮审查确认上轮 4 项问题已修复，体现了"检视→修复→复审"的良性循环。
- 开发者响应态度积极: 对 AI 意见未采取忽略策略，多数以改行 + 提交新 commit 方式响应；对不采纳的"上限 8 硬编码"也通过评审贴遗留问题确认机制闭环，而非沉默搁置。
- 人工检视补充价值: fumingquan 的验证报告要求实质性提升了 PR 自验证覆盖度（从单场景扩展到 6 类边界/异常场景）；lixiaocan 对 AI 意见的逐项 resolve 是本 PR 质量闭环的关键环节。
- 值得关注的遗留项:
MAX_ACTIVE_PSU_ARGS=8仍在两个 lua 脚本与 target.json（value2~value9）中各自定义，本次经确认参数数量无问题而闭环；后续若扩展参数上限（如 value10+）需多处同步修改，建议择机收敛为单一来源或对多余参数显式报错。
此回顾分析由 AI (opencode + GLM-5.3) 完成
感谢您为社区贡献新需求！请按照以下提示提供详细信息，以便我们更好地理解并跟进。
所属版本
openUBMC 26.09
版本分支
openUBMC main
简要说明
在ipmcset -d psuworkmode 命令中支持设置8电源主备模式
前置条件
BMC运行正常、电源在位
系统用户
运维人员
主成功场景
通过ipmcset -d psuworkmode -v 1 [active psuid]命令设置主备模式的主电源，剩余电源则为备用电源
非功能需求类型
兼容性影响评估
老版本仅支持设置两个电源为主电源，新方案可以兼容老版本
扩展场景（含异常场景）
无
周边依赖
读取/bmc/kepler/Chassis/1 的 DeviceSpecication属性，获取电源槽位号
约束
无