<fix>[allocator]: reject designated cross-cluster migration when strategy is Soft #3191
Conversation
Walkthrough此变更在资源绑定分配器中增加了对用户指定目标主机的预检查（若指定主机 UUID 不在绑定资源集合则立即失败），新增 12 个 KVM 迁移集成测试场景，并添加错误码常量 变更
序列图（无） 评估代码审查工作量🎯 3 (中等复杂度) | ⏱️ ~25 分钟 诗
Important Pre-merge checks failedPlease resolve all errors before merging. Addressing warnings is optional. ❌ Failed checks (1 error, 1 warning)
✅ Passed checks (1 passed)
✨ Finishing touches
📜 Recent review detailsConfiguration used: Path: http://open.zstack.ai:20001/code-reviews/zstack-cloud.yaml (via .coderabbit.yaml) Review profile: CHILL Plan: Pro 📒 Files selected for processing (3)
🧰 Additional context used📓 Path-based instructions (2)**/*.*⚙️ CodeRabbit configuration file
Files:
**/*.java⚙️ CodeRabbit configuration file
Files:
🧠 Learnings (2)📓 Common learnings📚 Learning: 2025-08-10T13:42:01.027ZApplied to files:
🔍 Remote MCP AtlassianMCPAdditional context from Jira (ZSTAC-75428)
🔇 Additional comments (10)
✏️ Tip: You can disable this entire section by setting Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ast-grep (0.40.5)utils/src/main/java/org/zstack/utils/clouderrorcode/CloudOperationsErrorCode.javaComment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
test/src/test/groovy/org/zstack/test/integration/kvm/vm/migrate/ResourceBindingMigrateVmCase.groovy (1)
266-292: resetVmToHost1Cluster1 辅助方法建议添加配置恢复此方法临时将
vm.ha.across.clusters设为true以便将 VM 迁回 host1-cluster1，但迁移完成后没有恢复原配置。虽然每个测试用例在开始时都会通过setResourceBindingConfig设置正确的配置，但建议在此方法结束前显式恢复配置，以提高代码清晰度和避免潜在的测试隔离问题。♻️ 可选的改进方案
migrateVm { vmInstanceUuid = vm.uuid hostUuid = host1.uuid } retryInSecs { VmInstanceVO vo = dbFindByUuid(vm.uuid, VmInstanceVO.class) assert vo.hostUuid == host1.uuid } + + // Restore haAcross to false (default state for most tests) + updateResourceConfig { + name = "vm.ha.across.clusters" + category = "vm" + resourceUuid = cluster1.uuid + value = "false" + } } }
📜 Review details
Configuration used: Path: http://open.zstack.ai:20001/code-reviews/zstack-cloud.yaml (via .coderabbit.yaml)
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
compute/src/main/java/org/zstack/compute/allocator/ResourceBindingAllocatorFlow.javatest/src/test/groovy/org/zstack/test/integration/kvm/vm/migrate/ResourceBindingMigrateVmCase.groovy
🧰 Additional context used
📓 Path-based instructions (2)
**/*.*
⚙️ CodeRabbit configuration file
**/*.*: - 代码里不应当有有中文，包括报错、注释等都应当使用正确的、无拼写错误的英文来写
Files:
compute/src/main/java/org/zstack/compute/allocator/ResourceBindingAllocatorFlow.javatest/src/test/groovy/org/zstack/test/integration/kvm/vm/migrate/ResourceBindingMigrateVmCase.groovy
**/*.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()），或使用枚举表达操作类型。- 命名应尽量用完整的单词组合表达意图，并在名称中体现数据类型或用途（例如在常量与变量名称中，将类型词放在末尾）。
- 避免使用魔法值（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:
compute/src/main/java/org/zstack/compute/allocator/ResourceBindingAllocatorFlow.java
🧠 Learnings (1)
📓 Common learnings
Learnt from: zstack-robot-1
Repo: MatheMatrix/zstack PR: 2360
File: network/src/main/java/org/zstack/network/l3/L3BasicNetwork.java:449-490
Timestamp: 2025-08-04T04:48:19.103Z
Learning: ZStack项目在cherry-pick操作中，即使发现了性能优化机会（如IP地址批量保存的内存优化），也严格遵循不做额外修改的政策，优先保证cherry-pick的完整性和一致性。
Learnt from: ZStack-Robot
Repo: MatheMatrix/zstack PR: 2489
File: storage/src/main/java/org/zstack/storage/snapshot/VolumeTree.java:471-545
Timestamp: 2025-08-22T05:36:40.467Z
Learning: In ZStack项目中，对于核心逻辑相关的代码，团队倾向于暂时不进行重构，即使代码复杂度较高，优先保证核心功能的稳定性。
Learnt from: ZStack-Robot
Repo: MatheMatrix/zstack PR: 2325
File: compute/src/main/java/org/zstack/compute/vm/VmMigrateCallExtensionFlow.java:29-29
Timestamp: 2025-07-24T05:53:10.246Z
Learning: 在ZStack项目的重构过程中，团队采用务实的优先级策略：优先完成影响运行时功能的代码重构，对于注释中的旧引用等非功能性问题可以延后处理，因为这些不会影响系统的实际运行。
Learnt from: zstack-robot-1
Repo: MatheMatrix/zstack PR: 2360
File: compute/src/main/java/org/zstack/compute/vm/StaticIpOperator.java:364-501
Timestamp: 2025-08-04T03:19:07.454Z
Learning: In ZStack project, developers may prefer to keep related validation logic together in a single method (like validateStaticIpTagsInApiMessage with 130+ lines) when the architecture is clear and there's no code reuse, rather than splitting into smaller methods based purely on single responsibility principle.
Learnt from: ZStack-Robot
Repo: MatheMatrix/zstack PR: 2419
File: plugin/sdnController/src/main/java/org/zstack/sdnController/SdnControllerBase.java:986-1067
Timestamp: 2025-08-13T02:31:40.023Z
Learning: 在ZStack项目中，团队倾向于保持统一的业务流程方法不进行拆分，即使方法较长也会维持在单个方法中以保持业务逻辑的完整性。
Learnt from: zstack-robot-2
Repo: MatheMatrix/zstack PR: 2496
File: plugin/sharedMountPointPrimaryStorage/src/main/java/org/zstack/storage/primary/smp/KvmBackend.java:2545-2566
Timestamp: 2025-08-24T07:35:42.793Z
Learning: 在 ZStack 代码库中，当响应类包含数值字段（如 size、actualSize）时，优先使用原始类型（long）而不是包装类型（Long），以避免 NPE 风险和不必要的装箱/拆箱操作。如果 Agent 端可能不设置该字段，应在 Agent 端确保设置默认值，而不是在使用端做 null 检查。
🔍 Remote MCP AtlassianMCP
Perfect! Now I have comprehensive context. Let me compile the findings:
Summary of Relevant Context for PR #3191
Issue Context (ZSTAC-75428)
This is a P1 (highest priority) bug marked as "mandatory to resolve in version 5.5.6" that was reported on May 30, 2025. The issue describes that when scene is set to "all" and strategy is set to "Soft", the zstack-cli can perform cross-cluster VM migration when cluster resources are sufficient, which is inconsistent with expected behavior.
The issue was escalated multiple times and reassigned to Lin Ma (马林) on January 12, 2026 for resolution in version 5.5.6.
Resource Binding Concepts
Based on cluster binding documentation, resource binding has two key components:
-
Scope Configuration (
resourceBinding.Scene):- Determines when resource binding constraints apply (at cluster and VM granularity via
vm.ha.across.clusters)
- Determines when resource binding constraints apply (at cluster and VM granularity via
-
Strategy (
resourceBinding.strategy): Defines fallback behavior when resources are exhausted:- Hard strategy: If no available hosts exist within the bound cluster range, the operation fails immediately with an error
- Soft strategy: If no available hosts exist within the bound cluster range, the system can relax constraints and migrate across clusters
What the PR Fixes
The change enforces that designated (explicitly specified) cross-cluster migrations must be rejected, regardless of strategy. The Soft strategy's relaxation now applies only to system auto-allocation scenarios when no hosts are available in the bound cluster—not when a user explicitly designates a target host in a different cluster.
This prevents the unintended behavior where Soft strategy would override explicit resource binding constraints for user-designated migrations.
🔇 Additional comments (6)
compute/src/main/java/org/zstack/compute/allocator/ResourceBindingAllocatorFlow.java (2)
149-156: 逻辑变更正确实现了预期行为此修改正确区分了两种场景：
- 用户显式指定目标主机：无论策略是 Hard 还是 Soft，跨集群迁移都应失败
- 系统自动分配主机：仅在此场景下 Soft 策略才放宽约束
注释清晰说明了行为变更，与 PR 目标和 ZSTAC-75428 的修复要求一致。
133-147: 此注释不适用 -getExtraData()返回的是初始化为new HashMap<>()的字段，不会为 null。字段虽然可通过setExtraData()被设置为 null，但项目约定是此类字段不应被设置为 null（参考项目中其他代码如DesignatedHostAllocatorFlow.java第 80-82 行，同样直接调用getExtraData().get()而无 null 检查）。按照项目编码指南，不应对可通过预检查避免的NullPointerException进行防御性处理；此处逻辑符合既有约定。test/src/test/groovy/org/zstack/test/integration/kvm/vm/migrate/ResourceBindingMigrateVmCase.groovy (4)
22-47: 测试覆盖全面，truth table 设计清晰测试类的文档注释详细描述了 12 种测试场景的 truth table，覆盖了：
- 用户指定目标主机（Cases 1-8）：不同 haAcross/strategy 组合下的跨集群迁移行为
- 系统自动分配主机（Cases 9-12）：资源充足/不足时的 Soft 策略放宽行为
Case 4 是核心修复验证，确保 Soft 策略下指定跨集群迁移仍会失败。
210-241: containsResourceBindingError 方法的关键字可能需要更新当前关键字列表为
["designated host", "bound resource", "binded resource"]，而ResourceBindingAllocatorFlow.java中的新错误消息使用的是"bound resource"（第 142 行），旧错误消息使用的是"binded resource"（第 155 行）。关键字匹配看起来是正确的，但建议确认递归检查 cause chain 的逻辑能正确处理嵌套错误。
388-418: 核心修复测试用例 (Case 4) 正确验证了 ZSTAC-75428 的修复此测试用例准确验证了：
- 配置：
haAcross=false, strategy=Soft, Scene=All- 操作：用户显式指定跨集群目标主机
- 预期：迁移失败（修复前会成功，修复后应失败）
断言逻辑完整：
- 验证操作返回错误
- 验证错误消息包含资源绑定相关关键字
625-668: Case 12 正确验证了 Soft 策略在自动分配场景下的放宽行为此测试验证了当集群内资源不足时，Soft 策略允许系统自动分配跨集群主机。与 Case 4 形成对比：
- Case 4：用户指定跨集群主机 → 失败（无论策略）
- Case 12：系统自动分配且集群资源不足 → Soft 策略放宽约束，成功迁移到跨集群主机
这正是 PR 要实现的行为差异。
MatheMatrix
force-pushed
the
sync/lin.ma/ZSTAC-75428
branch
from
69aba3e to
d15e2f1
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In
@test/src/test/groovy/org/zstack/test/integration/kvm/vm/migrate/ResourceBindingMigrateVmCase.groovy:
- Line 215: The keywords array contains a misspelling: replace the incorrect
"binded resource" with the correct term by removing "binded resource" from the
keywords list (the variable named keywords defined as ["designated host", "bound
resource", "binded resource"]); ensure the array only includes the correct
entries (e.g., ["designated host", "bound resource"]) so "binded" is not used
anywhere in the test.
🧹 Nitpick comments (1)
test/src/test/groovy/org/zstack/test/integration/kvm/vm/migrate/ResourceBindingMigrateVmCase.groovy (1)
427-435: 考虑移除调试日志语句。这些
logger.debug()调用看起来是开发调试期间留下的。虽然不影响测试功能，但在最终代码中可以考虑移除以保持测试输出整洁。♻️ 建议移除调试日志
assert result.error != null - // Debug output to see actual error structure - logger.debug("Error structure: details=${result.error.details}, " + - "globalErrorCode=${result.error.globalErrorCode}, " + - "cause=${result.error.cause}, " + - "causes=${result.error.causes}") - if (result.error.cause != null) { - logger.debug("Cause details: details=${result.error.cause.details}, " + - "globalErrorCode=${result.error.cause.globalErrorCode}") - } - // Check error message in details or cause chain (pagination may wrap the original error)
📜 Review details
Configuration used: Path: http://open.zstack.ai:20001/code-reviews/zstack-cloud.yaml (via .coderabbit.yaml)
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
compute/src/main/java/org/zstack/compute/allocator/ResourceBindingAllocatorFlow.javatest/src/test/groovy/org/zstack/test/integration/kvm/vm/migrate/ResourceBindingMigrateVmCase.groovy
🚧 Files skipped from review as they are similar to previous changes (1)
- compute/src/main/java/org/zstack/compute/allocator/ResourceBindingAllocatorFlow.java
🧰 Additional context used
📓 Path-based instructions (1)
**/*.*
⚙️ CodeRabbit configuration file
**/*.*: - 代码里不应当有有中文，包括报错、注释等都应当使用正确的、无拼写错误的英文来写
Files:
test/src/test/groovy/org/zstack/test/integration/kvm/vm/migrate/ResourceBindingMigrateVmCase.groovy
🧠 Learnings (1)
📓 Common learnings
Learnt from: zstack-robot-1
Repo: MatheMatrix/zstack PR: 2360
File: network/src/main/java/org/zstack/network/l3/L3BasicNetwork.java:449-490
Timestamp: 2025-08-04T04:48:19.103Z
Learning: ZStack项目在cherry-pick操作中，即使发现了性能优化机会（如IP地址批量保存的内存优化），也严格遵循不做额外修改的政策，优先保证cherry-pick的完整性和一致性。
Learnt from: ZStack-Robot
Repo: MatheMatrix/zstack PR: 2489
File: storage/src/main/java/org/zstack/storage/snapshot/VolumeTree.java:471-545
Timestamp: 2025-08-22T05:36:40.467Z
Learning: In ZStack项目中，对于核心逻辑相关的代码，团队倾向于暂时不进行重构，即使代码复杂度较高，优先保证核心功能的稳定性。
Learnt from: ZStack-Robot
Repo: MatheMatrix/zstack PR: 2325
File: compute/src/main/java/org/zstack/compute/vm/VmMigrateCallExtensionFlow.java:29-29
Timestamp: 2025-07-24T05:53:10.246Z
Learning: 在ZStack项目的重构过程中，团队采用务实的优先级策略：优先完成影响运行时功能的代码重构，对于注释中的旧引用等非功能性问题可以延后处理，因为这些不会影响系统的实际运行。
Learnt from: zstack-robot-1
Repo: MatheMatrix/zstack PR: 2360
File: compute/src/main/java/org/zstack/compute/vm/StaticIpOperator.java:364-501
Timestamp: 2025-08-04T03:19:07.454Z
Learning: In ZStack project, developers may prefer to keep related validation logic together in a single method (like validateStaticIpTagsInApiMessage with 130+ lines) when the architecture is clear and there's no code reuse, rather than splitting into smaller methods based purely on single responsibility principle.
Learnt from: ZStack-Robot
Repo: MatheMatrix/zstack PR: 2419
File: plugin/sdnController/src/main/java/org/zstack/sdnController/SdnControllerBase.java:986-1067
Timestamp: 2025-08-13T02:31:40.023Z
Learning: 在ZStack项目中，团队倾向于保持统一的业务流程方法不进行拆分，即使方法较长也会维持在单个方法中以保持业务逻辑的完整性。
Learnt from: zstack-robot-2
Repo: MatheMatrix/zstack PR: 2496
File: plugin/sharedMountPointPrimaryStorage/src/main/java/org/zstack/storage/primary/smp/KvmBackend.java:2545-2566
Timestamp: 2025-08-24T07:35:42.793Z
Learning: 在 ZStack 代码库中，当响应类包含数值字段（如 size、actualSize）时，优先使用原始类型（long）而不是包装类型（Long），以避免 NPE 风险和不必要的装箱/拆箱操作。如果 Agent 端可能不设置该字段，应在 Agent 端确保设置默认值，而不是在使用端做 null 检查。
🔍 Remote MCP AtlassianMCP, DevinDeepWiki
Relevant findings for PR #3191
-
Jira ZSTAC-75428 (P1, Bug) — summary, assignee, priority, fix version and timeline; worklog and comments confirm the bug reproduction (scene=all, strategy=Soft, haAcross=false) and that the fix is intended to make explicit cross-cluster target migrations fail when user-designated. Comments and attachments show the reproduced steps and the author (lin.ma) stating the exact change (fail when target is user-designated).
Key fields: status Open, priority P1, fix_versions: 5.5.6, assignee: lin.ma; comments: reproduction steps and “修复前: Soft 策略生效 → 允许跨集群 ❌ / 修复后: 检测到用户指定目标 → 直接失败 ✅”.
-
Confluence search for "resource binding" returned no matches (no additional docs found via Confluence search). This suggests no immediate Confluence pages indexed under that keyword or different wording is used.
-
Repository documentation structure (MatheMatrix/zstack) — contains relevant sections such as "3 Compute Management" (VM lifecycle, host management, KVM integration) and "8 Operational Patterns" (Workflow Engine and FlowChains, Resource Lifecycle Management) that are likely places for resource-binding implementation/behavior details if deeper review is needed.
Sources used:
- AtlassianMCP_jira_get_issue (ZSTAC-75428) — detailed issue, comments, attachments, worklogs.
- AtlassianMCP_confluence_search (query: resource binding) — no hits.
- DevinDeepWiki_read_wiki_structure (repo: MatheMatrix/zstack) — repo docs structure.
🔇 Additional comments (3)
test/src/test/groovy/org/zstack/test/integration/kvm/vm/migrate/ResourceBindingMigrateVmCase.groovy (3)
177-202: 测试组织结构良好！测试方法组织清晰，12 个测试用例完整覆盖了真值表中定义的所有场景，包括用户指定目标主机（Cases 1-8）和系统自动分配（Cases 9-12）两部分。测试命名规范，易于理解测试意图。
277-317: 辅助方法设计合理。
resetVmToHost1Cluster1()确保测试前 VM 状态一致，enableAllHosts()正确恢复主机状态。这些方法保证了测试用例之间的隔离性。
580-618: 测试清理逻辑正确。Case 10 和 Case 12 在测试结束后正确恢复了 host2 的状态（从 Maintenance 恢复为 Enabled），避免影响后续测试用例。这是良好的测试卫生实践。
MatheMatrix
force-pushed
the
sync/lin.ma/ZSTAC-75428
branch
from
d15e2f1 to
c0c78e0
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In
@test/src/test/groovy/org/zstack/test/integration/kvm/vm/migrate/ResourceBindingMigrateVmCase.groovy:
- Line 215: The keywords array in ResourceBindingMigrateVmCase.groovy uses the
incorrect word "binded resource"; update the keywords variable (keywords) to use
the correct "bound resource" spelling and remove any duplicate entries so the
array contains only unique, correctly spelled phrases (e.g., keep "designated
host" and a single "bound resource") to ensure text matching works as intended.
🧹 Nitpick comments (1)
test/src/test/groovy/org/zstack/test/integration/kvm/vm/migrate/ResourceBindingMigrateVmCase.groovy (1)
11-11: 存在未使用的导入。
KVMConstant在此文件中未被使用，建议移除以保持代码整洁。♻️ 建议修复
-import org.zstack.kvm.KVMConstant
📜 Review details
Configuration used: Path: http://open.zstack.ai:20001/code-reviews/zstack-cloud.yaml (via .coderabbit.yaml)
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
compute/src/main/java/org/zstack/compute/allocator/ResourceBindingAllocatorFlow.javatest/src/test/groovy/org/zstack/test/integration/kvm/vm/migrate/ResourceBindingMigrateVmCase.groovyutils/src/main/java/org/zstack/utils/clouderrorcode/CloudOperationsErrorCode.java
🧰 Additional context used
📓 Path-based instructions (2)
**/*.*
⚙️ CodeRabbit configuration file
**/*.*: - 代码里不应当有有中文，包括报错、注释等都应当使用正确的、无拼写错误的英文来写
Files:
utils/src/main/java/org/zstack/utils/clouderrorcode/CloudOperationsErrorCode.javacompute/src/main/java/org/zstack/compute/allocator/ResourceBindingAllocatorFlow.javatest/src/test/groovy/org/zstack/test/integration/kvm/vm/migrate/ResourceBindingMigrateVmCase.groovy
**/*.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()），或使用枚举表达操作类型。- 命名应尽量用完整的单词组合表达意图，并在名称中体现数据类型或用途（例如在常量与变量名称中，将类型词放在末尾）。
- 避免使用魔法值（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:
utils/src/main/java/org/zstack/utils/clouderrorcode/CloudOperationsErrorCode.javacompute/src/main/java/org/zstack/compute/allocator/ResourceBindingAllocatorFlow.java
🧠 Learnings (1)
📓 Common learnings
Learnt from: zstack-robot-1
Repo: MatheMatrix/zstack PR: 2360
File: network/src/main/java/org/zstack/network/l3/L3BasicNetwork.java:449-490
Timestamp: 2025-08-04T04:48:19.103Z
Learning: ZStack项目在cherry-pick操作中，即使发现了性能优化机会（如IP地址批量保存的内存优化），也严格遵循不做额外修改的政策，优先保证cherry-pick的完整性和一致性。
Learnt from: ZStack-Robot
Repo: MatheMatrix/zstack PR: 2489
File: storage/src/main/java/org/zstack/storage/snapshot/VolumeTree.java:471-545
Timestamp: 2025-08-22T05:36:40.467Z
Learning: In ZStack项目中，对于核心逻辑相关的代码，团队倾向于暂时不进行重构，即使代码复杂度较高，优先保证核心功能的稳定性。
Learnt from: ZStack-Robot
Repo: MatheMatrix/zstack PR: 2325
File: compute/src/main/java/org/zstack/compute/vm/VmMigrateCallExtensionFlow.java:29-29
Timestamp: 2025-07-24T05:53:10.246Z
Learning: 在ZStack项目的重构过程中，团队采用务实的优先级策略：优先完成影响运行时功能的代码重构，对于注释中的旧引用等非功能性问题可以延后处理，因为这些不会影响系统的实际运行。
Learnt from: zstack-robot-1
Repo: MatheMatrix/zstack PR: 2360
File: compute/src/main/java/org/zstack/compute/vm/StaticIpOperator.java:364-501
Timestamp: 2025-08-04T03:19:07.454Z
Learning: In ZStack project, developers may prefer to keep related validation logic together in a single method (like validateStaticIpTagsInApiMessage with 130+ lines) when the architecture is clear and there's no code reuse, rather than splitting into smaller methods based purely on single responsibility principle.
Learnt from: ZStack-Robot
Repo: MatheMatrix/zstack PR: 2419
File: plugin/sdnController/src/main/java/org/zstack/sdnController/SdnControllerBase.java:986-1067
Timestamp: 2025-08-13T02:31:40.023Z
Learning: 在ZStack项目中，团队倾向于保持统一的业务流程方法不进行拆分，即使方法较长也会维持在单个方法中以保持业务逻辑的完整性。
Learnt from: zstack-robot-2
Repo: MatheMatrix/zstack PR: 2496
File: plugin/sharedMountPointPrimaryStorage/src/main/java/org/zstack/storage/primary/smp/KvmBackend.java:2545-2566
Timestamp: 2025-08-24T07:35:42.793Z
Learning: 在 ZStack 代码库中，当响应类包含数值字段（如 size、actualSize）时，优先使用原始类型（long）而不是包装类型（Long），以避免 NPE 风险和不必要的装箱/拆箱操作。如果 Agent 端可能不设置该字段，应在 Agent 端确保设置默认值，而不是在使用端做 null 检查。
🧬 Code graph analysis (1)
compute/src/main/java/org/zstack/compute/allocator/ResourceBindingAllocatorFlow.java (1)
core/src/main/java/org/zstack/core/Platform.java (1)
Platform(72-1227)
🔍 Remote MCP AtlassianMCP, DevinDeepWiki
Summary of additional context relevant to PR #3191
-
Jira ZSTAC-75428: Open P1 bug assigned to lin.ma; summary confirms Soft strategy previously allowed cross-cluster migrations when scene=all and cluster had sufficient resources. Fix version includes 5.5.6; changelog/comments include reproduction steps, an attached screenshot, and an explicit intent: "修复前: Soft 策略生效 → 允许跨集群 ❌ / 修复后: 检测到用户指定目标 → 直接失败 ✅". (status Open, priority P1, assignee lin.ma).
-
Repository documentation structure: relevant sections exist under "3 Compute Management" (VM lifecycle, Host management, KVM integration) and "8 Operational Patterns" (Workflow Engine and Resource Lifecycle Management) which are likely places to consult for resource-binding and FlowChain behavior if deeper design/context is needed.
Sources used:
- AtlassianMCP_jira_get_issue (ZSTAC-75428) — for issue details, changelog, comments and attachments.
- DevinDeepWiki_read_wiki_structure (MatheMatrix/zstack) — repo documentation structure.
🔇 Additional comments (12)
compute/src/main/java/org/zstack/compute/allocator/ResourceBindingAllocatorFlow.java (3)
14-14: LGTM!新增
HostAllocatorConstant导入用于访问LocationSelector.host常量，符合代码需求。
149-156: LGTM! 逻辑修改正确实现了 PR 目标。现在 Soft 策略仅在系统自动分配（无指定目标主机）时才会放宽约束，符合 ZSTAC-75428 的修复意图：
- 用户指定目标主机时：无论策略为 Hard 或 Soft，跨集群迁移都会失败
- 系统自动分配时：Soft 策略仍可在绑定集群无可用主机时放宽约束
133-147: 该审查意见中的 NPE 风险不存在，代码是安全的。在 HostAllocatorSpec 类中，
extraData字段在声明时已初始化为new HashMap<>()（第24行），因此getExtraData()永远不会返回 null。这遵循了项目的既有约定：集合类型的 getter 方法返回初始化过的空集合，而非 null。整个代码库都依赖此约定，无需额外的防御性检查。Likely an incorrect or invalid review comment.
utils/src/main/java/org/zstack/utils/clouderrorcode/CloudOperationsErrorCode.java (1)
12935-12936: LGTM!新增的错误码常量
ORG_ZSTACK_COMPUTE_ALLOCATOR_10038遵循现有的命名规范和顺序编号模式，用于支持ResourceBindingAllocatorFlow中针对用户指定目标主机的跨集群迁移校验失败场景。test/src/test/groovy/org/zstack/test/integration/kvm/vm/migrate/ResourceBindingMigrateVmCase.groovy (8)
22-47: 文档清晰完整。真值表详细记录了所有 12 个测试场景，包括
haAcross、strategy、Scene、目标位置及预期结果，便于理解和维护。
65-175: 测试环境配置完整。环境配置包含两个集群、多个 KVM 主机、Ceph 存储及网络配置，完整覆盖了跨集群迁移测试所需的基础设施。
254-275: 辅助方法实现正确。
setResourceBindingConfig方法封装了三个资源配置的设置逻辑，便于在各测试用例中复用。
277-303: 辅助方法逻辑正确。
resetVmToHost1Cluster1方法通过临时允许跨集群迁移将 VM 重置到初始位置。由于每个测试用例都会调用setResourceBindingConfig重新配置参数，因此此处不恢复haAcross原值是可接受的。
406-440: 核心修复测试用例实现正确。此测试用例（Case 4）是 ZSTAC-75428 修复的核心验证，确保在
haAcross=false且strategy=Soft时，用户指定的跨集群迁移会失败。调试日志（427-435 行）有助于排查问题，可考虑在稳定后移除或降级为 trace 级别。
584-618: 资源不足场景测试正确。Case 10 正确测试了 Hard 策略在集群资源不足时的失败行为，并在测试结束后重新启用主机，确保测试隔离性。结合
enableAllHosts()在每个测试开始时调用，测试清理机制完善。
651-690: Soft 策略自动分配测试正确。Case 12 验证了 Soft 策略的关键差异：当用户未指定目标主机且绑定集群资源不足时，Soft 策略允许放宽约束跨集群迁移。这与 Case 4（用户指定目标时必须失败）形成对照，完整覆盖了 PR 目标中描述的行为。
177-202: 测试执行结构清晰。
test()方法按逻辑分为两部分：用户指定目标主机的迁移测试（Cases 1-8）和系统自动分配的迁移测试（Cases 9-12），完整覆盖了 ZSTAC-75428 修复所涉及的所有场景。
...c/test/groovy/org/zstack/test/integration/kvm/vm/migrate/ResourceBindingMigrateVmCase.groovy
Outdated
Show resolved
Hide resolved
MatheMatrix
force-pushed
the
sync/lin.ma/ZSTAC-75428
branch
2 times, most recently
from
b442558 to
a8df683
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
test/src/test/groovy/org/zstack/test/integration/kvm/vm/migrate/ResourceBindingMigrateVmCase.groovy (1)
447-455: 调试日志可考虑移除测试用例中的
logger.debug()调用在开发调试阶段有用，但对于已完成的测试可考虑移除，保持测试代码简洁。不过保留也无妨，因为使用的是debug级别。
📜 Review details
Configuration used: Path: http://open.zstack.ai:20001/code-reviews/zstack-cloud.yaml (via .coderabbit.yaml)
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
compute/src/main/java/org/zstack/compute/allocator/ResourceBindingAllocatorFlow.javatest/src/test/groovy/org/zstack/test/integration/kvm/vm/migrate/ResourceBindingMigrateVmCase.groovyutils/src/main/java/org/zstack/utils/clouderrorcode/CloudOperationsErrorCode.java
🧰 Additional context used
📓 Path-based instructions (2)
**/*.*
⚙️ CodeRabbit configuration file
**/*.*: - 代码里不应当有有中文，包括报错、注释等都应当使用正确的、无拼写错误的英文来写
Files:
utils/src/main/java/org/zstack/utils/clouderrorcode/CloudOperationsErrorCode.javacompute/src/main/java/org/zstack/compute/allocator/ResourceBindingAllocatorFlow.javatest/src/test/groovy/org/zstack/test/integration/kvm/vm/migrate/ResourceBindingMigrateVmCase.groovy
**/*.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()），或使用枚举表达操作类型。- 命名应尽量用完整的单词组合表达意图，并在名称中体现数据类型或用途（例如在常量与变量名称中，将类型词放在末尾）。
- 避免使用魔法值（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:
utils/src/main/java/org/zstack/utils/clouderrorcode/CloudOperationsErrorCode.javacompute/src/main/java/org/zstack/compute/allocator/ResourceBindingAllocatorFlow.java
🧠 Learnings (2)
📓 Common learnings
Learnt from: MatheMatrix
Repo: MatheMatrix/zstack PR: 2763
File: sdk/src/main/java/org/zstack/sdk/UpdateHostKernelInterfaceAction.java:31-31
Timestamp: 2025-10-20T11:27:25.928Z
Learning: UpdateHostKernelInterface API (`sdk/src/main/java/org/zstack/sdk/UpdateHostKernelInterfaceAction.java`) 在 PR #2763 时尚未被实际使用,因此对其参数约束的变更(如 name 字段从必需改为可选)不会造成破坏性影响。
Learnt from: MatheMatrix
Repo: MatheMatrix/zstack PR: 2410
File: compute/src/main/java/org/zstack/compute/vm/VmInstanceHelper.java:334-356
Timestamp: 2025-08-10T13:42:01.027Z
Learning: 在 ZStack 的 `VmInstanceHelper.validateVmNicParams` 方法中，当 vmNicParams 非空但 l3NetworkUuids 为空时的报错文案 "l3NetworkUuids and vmNicInventories mustn't both be empty or both be set" 需要保持不变，以维持与现有 i18n 的一致性，即使文案中提到的是 vmNicInventories 而非 vmNicParams。
Learnt from: MatheMatrix
Repo: MatheMatrix/zstack PR: 2823
File: plugin/kvm/src/main/java/org/zstack/kvm/KVMHost.java:786-831
Timestamp: 2025-10-28T02:29:38.803Z
Learning: APIUpdateHostnameMsg 的主机名有效性已在 API 层（HostApiInterceptor/VmHostnameUtils）完成校验；KVMHost.handle(UpdateHostnameMsg) 不应重复校验。
Learnt from: zstack-robot-1
Repo: MatheMatrix/zstack PR: 2360
File: network/src/main/java/org/zstack/network/l3/L3BasicNetwork.java:449-490
Timestamp: 2025-08-04T04:48:19.103Z
Learning: ZStack项目在cherry-pick操作中，即使发现了性能优化机会（如IP地址批量保存的内存优化），也严格遵循不做额外修改的政策，优先保证cherry-pick的完整性和一致性。
Learnt from: ZStack-Robot
Repo: MatheMatrix/zstack PR: 2489
File: storage/src/main/java/org/zstack/storage/snapshot/VolumeTree.java:471-545
Timestamp: 2025-08-22T05:36:40.467Z
Learning: In ZStack项目中，对于核心逻辑相关的代码，团队倾向于暂时不进行重构，即使代码复杂度较高，优先保证核心功能的稳定性。
Learnt from: ZStack-Robot
Repo: MatheMatrix/zstack PR: 2325
File: compute/src/main/java/org/zstack/compute/vm/VmMigrateCallExtensionFlow.java:29-29
Timestamp: 2025-07-24T05:53:10.246Z
Learning: 在ZStack项目的重构过程中，团队采用务实的优先级策略：优先完成影响运行时功能的代码重构，对于注释中的旧引用等非功能性问题可以延后处理，因为这些不会影响系统的实际运行。
Learnt from: zstack-robot-1
Repo: MatheMatrix/zstack PR: 2360
File: compute/src/main/java/org/zstack/compute/vm/StaticIpOperator.java:364-501
Timestamp: 2025-08-04T03:19:07.454Z
Learning: In ZStack project, developers may prefer to keep related validation logic together in a single method (like validateStaticIpTagsInApiMessage with 130+ lines) when the architecture is clear and there's no code reuse, rather than splitting into smaller methods based purely on single responsibility principle.
Learnt from: ZStack-Robot
Repo: MatheMatrix/zstack PR: 2419
File: plugin/sdnController/src/main/java/org/zstack/sdnController/SdnControllerBase.java:986-1067
Timestamp: 2025-08-13T02:31:40.023Z
Learning: 在ZStack项目中，团队倾向于保持统一的业务流程方法不进行拆分，即使方法较长也会维持在单个方法中以保持业务逻辑的完整性。
Learnt from: zstack-robot-2
Repo: MatheMatrix/zstack PR: 2496
File: plugin/sharedMountPointPrimaryStorage/src/main/java/org/zstack/storage/primary/smp/KvmBackend.java:2545-2566
Timestamp: 2025-08-24T07:35:42.793Z
Learning: 在 ZStack 代码库中，当响应类包含数值字段（如 size、actualSize）时，优先使用原始类型（long）而不是包装类型（Long），以避免 NPE 风险和不必要的装箱/拆箱操作。如果 Agent 端可能不设置该字段，应在 Agent 端确保设置默认值，而不是在使用端做 null 检查。
📚 Learning: 2025-08-10T13:42:01.027Z
Learnt from: MatheMatrix
Repo: MatheMatrix/zstack PR: 2410
File: compute/src/main/java/org/zstack/compute/vm/VmInstanceHelper.java:334-356
Timestamp: 2025-08-10T13:42:01.027Z
Learning: 在 ZStack 的 `VmInstanceHelper.validateVmNicParams` 方法中，当 vmNicParams 非空但 l3NetworkUuids 为空时的报错文案 "l3NetworkUuids and vmNicInventories mustn't both be empty or both be set" 需要保持不变，以维持与现有 i18n 的一致性，即使文案中提到的是 vmNicInventories 而非 vmNicParams。
Applied to files:
test/src/test/groovy/org/zstack/test/integration/kvm/vm/migrate/ResourceBindingMigrateVmCase.groovy
🔍 Remote MCP AtlassianMCP
Relevant Jira context (ZSTAC-75428)
-
Issue: ZSTAC-75428 — "scene 为 all strategy 为 soft，集群资源充足的情况下，zstack-cli可跨集群迁移，与预期不符" (P1, Open). Assignee: lin.ma. Created 2025-05-30; updated 2026-01-13.
-
Key comments:
- Reproducer & QA: vm.ha.across.clusters=false, resourceBinding.strategy=Soft, scene=All → CLI allowed cross-cluster migrate while UI forbids it (reproduction steps provided).
- Fix intent: detect user-designated target host and fail (i.e., reject designated cross-cluster migration even under Soft). Author confirms this PR implements the "fourth" truth-table case (detect user-designated → fail).
-
Practical implications for review:
- Behavior change is intentional and documented in Jira: designated-host migrations should always be rejected across clusters regardless of Soft strategy; Soft only relaxes constraints for system auto-allocation. Validate test coverage (new integration tests in PR) and the introduced error code usage aligns with this behavior.
🔇 Additional comments (9)
utils/src/main/java/org/zstack/utils/clouderrorcode/CloudOperationsErrorCode.java (1)
12935-12936: LGTM!新增的错误码常量
ORG_ZSTACK_COMPUTE_ALLOCATOR_10038遵循现有命名规范，序号正确递增，与ResourceBindingAllocatorFlow中对指定主机跨集群迁移的拒绝逻辑配合使用。compute/src/main/java/org/zstack/compute/allocator/ResourceBindingAllocatorFlow.java (2)
155-155: 拼写修正正确
bound是bind的正确过去分词形式，修正了原有的语法错误。
133-147: 指定主机校验逻辑正确此代码块在用户显式指定目标主机时，若该主机不在绑定资源集合内，将立即失败，不再考虑 Soft 策略放宽约束，符合 ZSTAC-75428 的修复目标。
错误消息包含了
strategy、scene和vm.ha.across.clusters的配置值，便于问题排查。spec.getExtraData()返回初始化为HashMap的extraData字段，不存在 NPE 风险，与代码库现有的调用模式一致。test/src/test/groovy/org/zstack/test/integration/kvm/vm/migrate/ResourceBindingMigrateVmCase.groovy (6)
23-48: 测试场景文档清晰完整测试类顶部的真值表清楚地记录了 12 个场景的预期行为，覆盖了用户指定目标主机和系统自动分配两种情况。这对于后续维护和理解测试意图非常有帮助。
Case 4 标注为
(Fixed)明确指出这是 ZSTAC-75428 的核心修复验证点。
211-253: 错误检查辅助方法设计合理
containsResourceBindingError方法递归遍历错误链（包括cause和causes字段），能够正确处理分页机制包装后的错误结构。关键字列表与ResourceBindingAllocatorFlow中的错误消息一致。
278-311: 重置辅助方法设计周全
resetVmToHost1Cluster1方法在迁移 VM 回初始状态前，临时将两个集群的vm.ha.across.clusters都设为true，确保重置操作不受当前测试配置影响。这是一个考虑周到的实现方式。
426-460: 核心修复测试验证完整Case 4 是本次修复的核心验证点，测试了
haAcross=false+strategy=Soft+ 指定跨集群目标主机的场景。注释清晰说明了修复前后的行为差异，断言验证了错误消息包含预期的关键字。
671-710: 自动分配场景下 Soft 策略放宽行为验证正确Case 12 验证了当集群资源不足且未指定目标主机时，Soft 策略会放宽约束允许跨集群迁移。这与 Case 4 形成对比，清晰展示了修复后的行为区分：
- 指定目标主机：即使 Soft 策略也不允许跨集群
- 系统自动分配：Soft 策略在资源不足时放宽约束
测试结束时正确恢复了 host2 状态。
178-203: 测试执行顺序和覆盖率完整
test()方法按顺序执行所有 12 个测试场景，分为两部分：
- 用户指定目标主机（Cases 1-8）
- 系统自动分配（Cases 9-12）
覆盖了真值表中的所有组合情况，为
ResourceBindingAllocatorFlow的行为变更提供了充分的回归测试保障。
| return false | ||
| } | ||
|
|
||
| def keywords = ["designated host", "bound resource", "binded resource"] |
There was a problem hiding this comment.
Comment from lin.ma:
已调整
…tegy is Soft When user explicitly designates a target host for VM migration, ResourceBindingAllocatorFlow should reject cross-cluster migration regardless of whether strategy is Hard or Soft. Before: Soft strategy would relax the constraint and allow cross-cluster After: Designated cross-cluster migration fails even with Soft strategy The Soft strategy now only relaxes constraints during system auto-allocation when no hosts are available in the bound cluster. Resolves: ZSTAC-75428 Change-Id: I6b76656d7069736a6c707262657465696c717668
MatheMatrix
force-pushed
the
sync/lin.ma/ZSTAC-75428
branch
from
a8df683 to
32939cf
Compare
When user explicitly designates a target host for VM migration,
ResourceBindingAllocatorFlow should reject cross-cluster migration
regardless of whether strategy is Hard or Soft.
Before: Soft strategy would relax the constraint and allow cross-cluster
After: Designated cross-cluster migration fails even with Soft strategy
The Soft strategy now only relaxes constraints during system auto-allocation
when no hosts are available in the bound cluster.
Resolves: ZSTAC-75428
Change-Id: I6b76656d7069736a6c707262657465696c717668
sync from gitlab !9010