<fix>[storage-device]: alarm when multipath default config changed

[MatheMatrix]

1.alarm when multipath default config changed
2.fixed multipath find_multipaths value is yes
3.automatically enable multipath service when installing the os

Resolves/Related: ZSTAC-77506

Change-Id: I7a797462746a67706b6f676d7a726670696f6871

sync from gitlab !8709

[coderabbitai]

高层次概述

在 HostCanonicalEvents 类中新增了一个多路径配置变更事件常量 HOST_MULTIPATH_CONFIG_CHANGED 和对应的数据类 MultipathConfigChangedData，包含主机UUID和配置详情字段。

变更

变更集群 / 文件	变更摘要
事件常量和数据类增强 header/src/main/java/org/zstack/header/host/HostCanonicalEvents.java	新增常量 HOST_MULTIPATH_CONFIG_CHANGED 和内部类 MultipathConfigChangedData（含 hostUuid 和 details 属性及其访问器）

代码审查工作量评估

🎯 1 (平凡) | ⏱️ ~3 分钟

• 变更涉及简单的常量和数据类定义，无复杂业务逻辑
• 只有一个文件被修改
• 遵循现有编码模式和约定

诗

🐰 又一新事件降临，多路径悄然而至，
常量在列，数据类立，主机之声响彻云霄，
配置之变，细节可知，事件之树又添新枝。✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	标题准确地反映了pull request的主要目的,即在多路径默认配置更改时添加告警功能。
Description check	✅ Passed	描述与代码变更相关联,列出了三个主要目标,与pull request的实现内容一致。

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch sync/shan.wu/fix-ZSTAC-79927@@3

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

header/src/main/java/org/zstack/header/host/HostCanonicalEvents.java (1)

408-429: 数据类结构符合现有模式，建议考虑方法顺序和字段完整性。

该数据类的整体设计与文件中其他事件数据类保持一致，正确使用了 @NeedJsonSchema 注解和标准的 getter/setter 模式。

不过有以下两点建议：

1. 方法顺序优化（可选）： getter/setter 的顺序（先 details 后 hostUuid）与字段声明顺序（先 hostUuid 后 details）不一致。建议调整方法顺序与字段声明保持一致，提升代码可读性。

2. 确认是否需要 eventTime 字段： 同文件中的 HostMountData（第 345 行）和 HostPhysicalNicStatusData（第 356 行）都包含了 eventTime 字段用于记录事件发生时间。请确认 MultipathConfigChangedData 是否也需要该字段以保持一致性。

可选的重构建议（调整方法顺序）：

     @NeedJsonSchema
     public static class MultipathConfigChangedData {
         private String hostUuid;
         private String details;
 
-        public String getDetails() {
-            return details;
+        public String getHostUuid() {
+            return hostUuid;
         }
 
-        public void setDetails(String details) {
-            this.details = details;
+        public void setHostUuid(String hostUuid) {
+            this.hostUuid = hostUuid;
         }
 
-        public String getHostUuid() {
-            return hostUuid;
+        public String getDetails() {
+            return details;
         }
 
-        public void setHostUuid(String hostUuid) {
-            this.hostUuid = hostUuid;
+        public void setDetails(String details) {
+            this.details = details;
         }
     }

如需添加 eventTime 字段，可参考以下实现：

@NeedJsonSchema
public static class MultipathConfigChangedData {
    private String hostUuid;
    private String details;
    private Long eventTime = System.currentTimeMillis();

    // ... getters and setters
}

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 1d22c42 and a4d0bf4.

📒 Files selected for processing (1)

• header/src/main/java/org/zstack/header/host/HostCanonicalEvents.java (2 hunks)

🧰 Additional context used

📓 Path-based instructions (1)

**/*.java

⚙️ CodeRabbit configuration file

**/*.java: ## 1. API 设计要求

• API 命名：
  • API 名称必须唯一，不能重复。
  • API 消息类需要继承 APIMessage；其返回类必须继承 APIReply 或 APIEvent，并在注释中用 @RestResponse 进行标注。
  • API 消息上必须添加注解 @RestRequest，并满足如下规范：
    • path:
      • 针对资源使用复数形式。
      • 当 path 中引用消息类变量时，使用 {variableName} 格式。
    • HTTP 方法对应：
      • 查询操作 → HttpMethod.GET
      • 更新操作 → HttpMethod.PUT
      • 创建操作 → HttpMethod.POST
      • 删除操作 → HttpMethod.DELETE
  • API 类需要实现 __example__ 方法以便生成 API 文档，并确保生成对应的 Groovy API Template 与 API Markdown 文件。

---

2. 命名与格式规范

• 类名：

  • 使用 UpperCamelCase 风格。
  • 特殊情况：
    • VO/AO/EO 类型类除外。
    • 抽象类采用 Abstract 或 Base 前缀/后缀。
    • 异常类应以 Exception 结尾。
    • 测试类需要以 Test 或 Case 结尾。

• 方法名、参数名、成员变量和局部变量：

  • 使用 lowerCamelCase 风格。

• 常量命名：

  • 全部大写，使用下划线分隔单词。
  • 要求表达清楚，避免使用含糊或不准确的名称。

• 包名：

  • 统一使用小写，使用点分隔符，每个部分应是一个具有自然语义的英文单词（参考 Spring 框架的结构）。

• 命名细节：

  • 避免在父子类或同一代码块中出现相同名字的成员或局部变量，防止混淆。
  • 命名缩写：
    • 不允许使用不必要的缩写，如：AbsSchedulerJob、condi、Fu 等。应使用完整单词提升可读性。

---

3. 编写自解释代码

• 意图表达：

  • 避免使用布尔型参数造成含义不明确。例如：
    • 对于 stopAgent(boolean ignoreError)，建议拆分为不同函数（如 stopAgentIgnoreError()），或使用枚举表达操作类型。
  • 命名应尽量用完整的单词组合表达意图，并在名称中体现数据类型或用途（例如在常量与变量名称中，将类型词放在末尾）。

• 注释：

  • 代码应尽量做到自解释，对少于两行的说明可以直接写在代码中。
  • 对于较长的注释，需要仔细校对并随代码更新，确保内容正确。
  • 接口方法不应有多余的修饰符（例如 public），且必须配有有效的 Javadoc 注释。

---

4. 流程控制和结构优化

• if...else 的使用：

  • 应尽量减少 if...else 结构的使用，建议：
    • 限制嵌套层级最多为两层，且内层不应再出现 else 分支。
    • 尽早返回（Early Return），将条件判断中的处理逻辑提前结束或抽成独立方法。
    • 使用 Java Stream 或 Lambda 表达式代替冗长的循环与条件判断。

• 条件判断：

  • if 条件表达不宜过长或过于复杂，必要时可以将条件抽成 boolean 变量描述。

• 代码块长度：

  • 单个 if 代码块不宜超过一屏显示，以提高可读性和后续维护性。

---

5. 异常处理与日志

• 捕获异常的原则：
  • 对于可以通过预检查避免的 RuntimeException（如 NullPointerException、IndexOutOfBoundsException 等），不建议使用 try-catch 来进行处理。
  • 捕获异常应仅用于处理真正的意外情况，不应将异常逻辑当作正常流程控制。
  • 在必要时，应继续抛出异常，使上层业务处理者可以转换为用户友好的错误提示。
  • 使用 try-with-resources 语法管理资源，确保在 finally 块中正确关闭资源，并避免在 finally 中返回值。
    ...

Files:

• header/src/main/java/org/zstack/header/host/HostCanonicalEvents.java

🔇 Additional comments (1)

header/src/main/java/org/zstack/header/host/HostCanonicalEvents.java (1)

29-29: 常量声明符合规范。

新增的事件常量命名和路径格式与文件中其他事件常量保持一致，遵循了命名规范。