Skip to content

Conversation

@zstack-robot-1
Copy link
Collaborator

Resolves: ZSTAC-81338

Change-Id: I71686f716a66726b6362786c6f78656d65666867

(cherry picked from commit c90da01)

sync from gitlab !9031

Resolves: ZSTAC-81338

Change-Id: I71686f716a66726b6362786c6f78656d65666867


(cherry picked from commit c90da01)
@coderabbitai
Copy link

coderabbitai bot commented Jan 16, 2026

总体概览

ExternalPrimaryStorage 类的 doDownloadImageCache 方法中添加了早期返回逻辑。当不支持多空间且已存在缓存镜像时,直接返回第一个缓存镜像,跳过迭代和下载流程。

变化详情

同类文件组 / 文件路径 变化摘要
缓存下载优化
storage/src/main/java/org/zstack/storage/addon/primary/ExternalPrimaryStorage.java
doDownloadImageCache 方法中添加早期返回检查,当多空间不被支持且存在缓存时,立即返回第一个缓存镜像,改变控制流避免不必要的下载操作

代码审查工作量估估

🎯 2 (简单) | ⏱️ ~10分钟

诗韵

🐰 缓存好友来相助,
不必远山再跋涉,
早早回返省力气,
存储之路更轻松!

🚥 Pre-merge checks | ✅ 2 | ❌ 1
❌ 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%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (2 passed)
Check name Status Explanation
Title check ✅ Passed 标题完全遵循 [scope]: 格式要求,58个字符以内,清晰描述了存储空间缓存检查的修复。
Description check ✅ Passed PR描述包含问题编号ZSTAC-81338和提交信息,与代码变更相关,描述了樱桃选择和同步来源。

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
  • 📝 Generate docstrings


📜 Recent review details

Configuration used: Path: http://open.zstack.ai:20001/code-reviews/zstack-cloud.yaml (via .coderabbit.yaml)

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d590879 and 9bc0f00.

📒 Files selected for processing (1)
  • storage/src/main/java/org/zstack/storage/addon/primary/ExternalPrimaryStorage.java
🧰 Additional context used
📓 Path-based instructions (2)
**/*.*

⚙️ CodeRabbit configuration file

**/*.*: - 代码里不应当有有中文,包括报错、注释等都应当使用正确的、无拼写错误的英文来写

Files:

  • storage/src/main/java/org/zstack/storage/addon/primary/ExternalPrimaryStorage.java
**/*.java

⚙️ CodeRabbit configuration file

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

  • API 命名:
    • API 名称必须唯一,不能重复。
    • API 消息类需要继承 APIMessage;其返回类必须继承 APIReplyAPIEvent,并在注释中用 @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 类型类除外。
      • 抽象类采用 AbstractBase 前缀/后缀。
      • 异常类应以 Exception 结尾。
      • 测试类需要以 TestCase 结尾。
  • 方法名、参数名、成员变量和局部变量:

    • 使用 lowerCamelCase 风格。
  • 常量命名:

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

    • 统一使用小写,使用点分隔符,每个部分应是一个具有自然语义的英文单词(参考 Spring 框架的结构)。
  • 命名细节:

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

3. 编写自解释代码

  • 意图表达:

    • 避免使用布尔型参数造成含义不明确。例如:
      • 对于 stopAgent(boolean ignoreError),建议拆分为不同函数(如 stopAgentIgnoreError()),或使用枚举表达操作类型。
    • 命名应尽量用完整的单词组合表达意图,并在名称中体现数据类型或用途(例如在常量与变量名称中,将类型词放在末尾)。
    • 避免使用魔法值(Magic Value):
      • 直接使用未经定义的数值或字符串(如 if (status == 5))应替换为枚举或常量。

      • 示例:

      • // 错误示例:魔法值

      • if (user.getStatus() == 5) { ... }

      • // 正确示例:常量或枚举

      • public static final int STATUS_ACTIVE = 5;

      • if (user.getStatus() == STATUS_ACTIVE) { ... }

      • // 或使用枚举

      • enum UserStatus { ACTIVE, INACTIVE }

  • 注释:

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

4. 流程控制和结构优化

  • if...else 的使用:

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

    • if 条件表达不宜过长或过于复杂,必要时可以将条件抽成 boolean 变量描述。
  • 代码块长度:
    ...

Files:

  • storage/src/main/java/org/zstack/storage/addon/primary/ExternalPrimaryStorage.java
🔍 Remote MCP AtlassianMCP

Jira Issue Context - ZSTAC-81338

Issue Summary: Creating VM from snapshot failed (【星飞MTBF】从快照创建云主机失败)

Status: Resolved (P0 - Critical Priority)

Key Background Information:

Root Cause Analysis:

  • Trigger: Creating VM from snapshot

  • Introduction Reason:

    • ZBS cannot clone across pools
    • ZBS now supports multi-space
    • When implementing these features, a check was added to verify if resources are in the same location
    • However, this check was not made compatible with storage systems that do not support multi-space
    • No testing was conducted for this scenario
  • Root Cause: Lack of compatibility between multi-space and single-space storage systems

Solution:

  • Retain the original single-space bypass image download logic and open it for storage systems that don't support multi-space

Related Information:

Key Insight: This PR is a cherry-pick of the fix that maintains backward compatibility by allowing single-space storage systems to bypass image downloads when multi-space is not supported, fixing a regression introduced in version 5.5.0.

✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.


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

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
storage/src/main/java/org/zstack/storage/addon/primary/ExternalPrimaryStorage.java (1)

1217-1226: 优先选择 ready 且匹配 allocatedUrl 的缓存,避免返回无效缓存

当前在单空间直接返回 caches.get(0),但 caches 未过滤 state 且无排序,可能返回非 ready/已失效或不符合 allocatedUrl 的缓存,导致后续失败或路径不匹配。建议先筛选 ready,并在 allocatedUrl 提供时优先匹配。

🔧 建议修改
-        List<ImageCacheVO> caches = Q.New(ImageCacheVO.class)
-                .eq(ImageCacheVO_.primaryStorageUuid, self.getUuid())
-                .eq(ImageCacheVO_.imageUuid, image.getUuid())
-                .list();
-
-        if (!controller.reportCapabilities().isSupportMultiSpace() && !caches.isEmpty()) {
-            // TODO check exists in ps
-            completion.success(caches.get(0).toInventory());
-            return;
-        }
+        List<ImageCacheVO> caches = Q.New(ImageCacheVO.class)
+                .eq(ImageCacheVO_.primaryStorageUuid, self.getUuid())
+                .eq(ImageCacheVO_.imageUuid, image.getUuid())
+                .eq(ImageCacheVO_.state, ImageCacheState.ready)
+                .list();
+
+        if (!controller.reportCapabilities().isSupportMultiSpace() && !caches.isEmpty()) {
+            // TODO check exists in ps
+            ImageCacheVO selected = caches.get(0);
+            if (allocatedUrl != null) {
+                for (ImageCacheVO cache : caches) {
+                    ImageCacheInventory inv = cache.toInventory();
+                    if (ImageCacheUtil.getImageCachePath(inv).startsWith(allocatedUrl)) {
+                        selected = cache;
+                        break;
+                    }
+                }
+            }
+            completion.success(selected.toInventory());
+            return;
+        }
📜 Review details

Configuration used: Path: http://open.zstack.ai:20001/code-reviews/zstack-cloud.yaml (via .coderabbit.yaml)

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d590879 and 9bc0f00.

📒 Files selected for processing (1)
  • storage/src/main/java/org/zstack/storage/addon/primary/ExternalPrimaryStorage.java
🧰 Additional context used
📓 Path-based instructions (2)
**/*.*

⚙️ CodeRabbit configuration file

**/*.*: - 代码里不应当有有中文,包括报错、注释等都应当使用正确的、无拼写错误的英文来写

Files:

  • storage/src/main/java/org/zstack/storage/addon/primary/ExternalPrimaryStorage.java
**/*.java

⚙️ CodeRabbit configuration file

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

  • API 命名:
    • API 名称必须唯一,不能重复。
    • API 消息类需要继承 APIMessage;其返回类必须继承 APIReplyAPIEvent,并在注释中用 @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 类型类除外。
      • 抽象类采用 AbstractBase 前缀/后缀。
      • 异常类应以 Exception 结尾。
      • 测试类需要以 TestCase 结尾。
  • 方法名、参数名、成员变量和局部变量:

    • 使用 lowerCamelCase 风格。
  • 常量命名:

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

    • 统一使用小写,使用点分隔符,每个部分应是一个具有自然语义的英文单词(参考 Spring 框架的结构)。
  • 命名细节:

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

3. 编写自解释代码

  • 意图表达:

    • 避免使用布尔型参数造成含义不明确。例如:
      • 对于 stopAgent(boolean ignoreError),建议拆分为不同函数(如 stopAgentIgnoreError()),或使用枚举表达操作类型。
    • 命名应尽量用完整的单词组合表达意图,并在名称中体现数据类型或用途(例如在常量与变量名称中,将类型词放在末尾)。
    • 避免使用魔法值(Magic Value):
      • 直接使用未经定义的数值或字符串(如 if (status == 5))应替换为枚举或常量。

      • 示例:

      • // 错误示例:魔法值

      • if (user.getStatus() == 5) { ... }

      • // 正确示例:常量或枚举

      • public static final int STATUS_ACTIVE = 5;

      • if (user.getStatus() == STATUS_ACTIVE) { ... }

      • // 或使用枚举

      • enum UserStatus { ACTIVE, INACTIVE }

  • 注释:

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

4. 流程控制和结构优化

  • if...else 的使用:

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

    • if 条件表达不宜过长或过于复杂,必要时可以将条件抽成 boolean 变量描述。
  • 代码块长度:
    ...

Files:

  • storage/src/main/java/org/zstack/storage/addon/primary/ExternalPrimaryStorage.java
🔍 Remote MCP AtlassianMCP

Jira Issue Context - ZSTAC-81338

Issue Summary: Creating VM from snapshot failed (【星飞MTBF】从快照创建云主机失败)

Status: Resolved (P0 - Critical Priority)

Key Background Information:

Root Cause Analysis:

  • Trigger: Creating VM from snapshot

  • Introduction Reason:

    • ZBS cannot clone across pools
    • ZBS now supports multi-space
    • When implementing these features, a check was added to verify if resources are in the same location
    • However, this check was not made compatible with storage systems that do not support multi-space
    • No testing was conducted for this scenario
  • Root Cause: Lack of compatibility between multi-space and single-space storage systems

Solution:

  • Retain the original single-space bypass image download logic and open it for storage systems that don't support multi-space

Related Information:

Key Insight: This PR is a cherry-pick of the fix that maintains backward compatibility by allowing single-space storage systems to bypass image downloads when multi-space is not supported, fixing a regression introduced in version 5.5.0.

✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants