Pull request overview

Adds the “Instance Boot Group” feature (per design spec) across the CloudStack stack, including new API surface, persistence schema, readiness evaluation/checkers, and UI flows to manage members, boot order, and readiness rules.

Changes:

• Introduces Instance Boot Group core entities (DB tables/views + VO/DAO/query-join) and API commands/responses for CRUD, membership, start/stop/reboot sequencing, and readiness rules.
• Adds readiness rule execution plumbing (VR-dispatched ping/port checks, KVM guest-agent liveness command/wrapper) and Spring wiring/registries for checker strategy discovery.
• Adds UI navigation and screens for boot groups (listing/details/members, add/remove members, update boot order, manage/view readiness rules) plus i18n strings and icon wiring.

Reviewed changes

Copilot reviewed 82 out of 83 changed files in this pull request and generated 3 comments.

ui/src/core/lazy_lib/icons_use.js:365

• VerticalAlignMiddleOutlined is registered twice on the Vue app, which is redundant and can mask issues when refactoring the icon list. Remove the duplicate component registration.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Pull request overview

Copilot reviewed 82 out of 83 changed files in this pull request and generated no new comments.

ui/src/views/compute/UpdateInstanceBootGroupMemberOrder.vue:1

• a-form's @finish handler is invoked with form values (not a DOM event). As written, handleSubmit will throw when called from @finish because e.preventDefault() is executed on a non-event/undefined. Make handleSubmit tolerant of non-event invocations (e.g., only call preventDefault when present) or split into separate submit handlers for click vs. finish.
  ui/src/views/compute/UpdateInstanceBootGroupMemberOrder.vue:1
• a-form's @finish handler is invoked with form values (not a DOM event). As written, handleSubmit will throw when called from @finish because e.preventDefault() is executed on a non-event/undefined. Make handleSubmit tolerant of non-event invocations (e.g., only call preventDefault when present) or split into separate submit handlers for click vs. finish.
  ui/src/views/compute/AddInstanceBootGroupMember.vue:1
• Same issue as the update-order modal: @finish passes form values, not a DOM event, so e.preventDefault() can throw and break submission. Update handleSubmit to safely handle calls from both @finish and button/keyboard events.
  ui/src/views/compute/AddInstanceBootGroupMember.vue:1
• Same issue as the update-order modal: @finish passes form values, not a DOM event, so e.preventDefault() can throw and break submission. Update handleSubmit to safely handle calls from both @finish and button/keyboard events.
  ui/src/views/compute/AddInstanceBootGroupMember.vue:1
• The form currently only validates order, so it’s possible to submit without selecting a VM/InstanceGroup, relying on backend errors. Add client-side required validation for virtualmachineid when membertype is VirtualMachine, and for instancegroupid when membertype is InstanceGroup (and consider clearing validation errors when toggling member type).
  ui/src/views/compute/AddInstanceBootGroupMember.vue:1
• The form currently only validates order, so it’s possible to submit without selecting a VM/InstanceGroup, relying on backend errors. Add client-side required validation for virtualmachineid when membertype is VirtualMachine, and for instancegroupid when membertype is InstanceGroup (and consider clearing validation errors when toggling member type).
  ui/src/views/compute/AddInstanceBootGroupMember.vue:1
• The form currently only validates order, so it’s possible to submit without selecting a VM/InstanceGroup, relying on backend errors. Add client-side required validation for virtualmachineid when membertype is VirtualMachine, and for instancegroupid when membertype is InstanceGroup (and consider clearing validation errors when toggling member type).
  core/src/main/java/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java:1
• This handler hard-codes _eachTimeout to 60 seconds and ignores the wait set on the command (cmd.setWait(...) is used by the callers to respect an attempt budget). This can cause attempts to exceed the intended budget or time out too early. Use the command’s wait value (or derive _eachTimeout from it) instead of a fixed constant.
  server/src/main/java/org/apache/cloudstack/vm/bootgroup/readiness/VrPingChecker.java:1
• The code casts Answer to InstanceReadinessCheckAnswer without verifying the type or checking answer.getResult(). In mixed-version/upgrade scenarios or when the VR can’t execute the script, the agent may return a different Answer type or a failure response, leading to ClassCastException and breaking readiness evaluation. Guard with instanceof, handle !answer.getResult() explicitly, and surface answer.getDetails() as the error message.
  server/src/main/java/org/apache/cloudstack/vm/bootgroup/readiness/PortCheckChecker.java:1
• Same unsafe cast pattern as VrPingChecker: Answer is cast to InstanceReadinessCheckAnswer without instanceof/getResult() checks. This can crash the checker and abort readiness computation. Add defensive checks and handle failed answers by returning Status.Error with the agent-provided details.
  engine/schema/src/main/java/com/cloud/vm/dao/InstanceBootGroupReadinessCheckResultDaoImpl.java:1
• This upsert is not atomic: concurrent writers can both observe existing == null and then attempt persist, violating the unique key on (rule_id, vm_id) and causing intermittent failures under parallel readiness evaluation. Wrap this in a transaction with appropriate locking, or implement a DB-level upsert pattern (e.g., try-insert then update on duplicate) so concurrent updates are safe.
  core/src/main/java/org/apache/cloudstack/vm/bootgroup/readiness/InstanceReadinessCheckAnswer.java:1
• The answer parsing relies on a string delimiter (&&) and throws a runtime exception if the format isn't exactly as expected. Any unexpected script output (including delimiter collisions) will bubble up as an exception and can disrupt readiness evaluation. Consider switching the VR script to emit structured output (e.g., JSON with stdout/stderr/exitcode fields) and make the parser fail-soft (returning exitcode=-1 with a descriptive stderr) rather than throwing.

Pull request overview

Copilot reviewed 82 out of 83 changed files in this pull request and generated no new comments.

Previously missed (3) — in code that hasn't changed since the last review.

core/src/main/java/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java:500

• InstanceReadinessCheckCommand.setWait(...) is computed from the remaining budget, but this handler hardcodes _eachTimeout to 60s. This makes the command’s per-attempt wait budget ineffective (the VR script execution timeout can exceed the intended budget).
  plugins/hypervisors/kvm/src/main/java/com/cloud/hypervisor/kvm/resource/wrapper/LibvirtCheckGuestAgentLivenessCommandWrapper.java:74
• The wrapper uses a fixed 5s timeout for qemuAgentCommand(...) and ignores command.getWait(), even though the caller sets the command wait from the remaining readiness budget. This can cause false negatives when the readiness attempt budget is higher than 5s.
  server/src/main/java/org/apache/cloudstack/vm/bootgroup/InstanceBootGroupMembershipGuard.java:99
• validateVmEligibleForGroupMembership only checks the first Instance Group mapping for the VM (currentMappings.get(0)). Since instance_group_vm_map does not enforce one-group-per-VM, a VM can be in multiple instance groups, and this can miss a disqualifying group that is already a boot-group member.

ui/src/views/compute/AddInstanceBootGroupMember.vue:120

• The form validation only enforces order, so it’s possible to submit without selecting a VM/instance group, which will send an API request missing the required virtualmachineid/instancegroupid parameter.

Pull request overview

Copilot reviewed 107 out of 108 changed files in this pull request and generated no new comments.

ui/src/views/compute/UpdateInstanceBootGroupMemberOrder.vue:1

• handleSubmit unconditionally calls e.preventDefault(), but <a-form @finish> emits validated values (not a DOM event) in Ant Design Vue. This will throw at runtime when the submit originates from @finish. Split the concerns (e.g., handleFinish(values) vs click/keypress handler) or guard with if (e?.preventDefault) e.preventDefault() and rely on the @finish payload instead of re-validating.
  core/src/main/java/org/apache/cloudstack/vm/bootgroup/readiness/InstanceReadinessCheckAnswer.java:1
• On readiness-check failures, getResult() is typically false but getDetails() may still contain the structured stdout&&stderr&&exitcode output from the VR script. Current logic skips parsing in that case, loses exitcode, and collapses the entire payload into stderr. Parse based on the presence/shape of the delimiter (or always attempt to parse when details contains &&) regardless of getResult(), and only fall back to the sentinel -1 when the payload is truly unstructured.
  server/src/main/java/org/apache/cloudstack/vm/bootgroup/InstanceBootGroupMembershipGuard.java:1
• This checks only the first instance-group mapping (get(0)), but listByInstanceId returns a list. If a VM can belong to multiple instance groups, this can incorrectly allow membership when any non-first group is already part of a boot group. Iterate all mappings and reject if any mapped group is already a boot-group member.
  plugins/hypervisors/kvm/src/main/java/com/cloud/hypervisor/kvm/resource/wrapper/LibvirtCheckGuestAgentLivenessCommandWrapper.java:1
• JSON parsing errors from new JsonParser().parse(result) are not caught (only LibvirtException is), so malformed/non-JSON agent output can throw and fail the wrapper unexpectedly. Also, the JSON is parsed twice. Parse once and catch JSON parse/runtime exceptions, returning a non-alive answer with a safe diagnostic message.
  core/src/main/java/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java:1
• This hard-codes _eachTimeout to 60 seconds via NumbersUtil.parseInt(\"60\", 60), which is effectively a constant and obscures intent. Prefer Duration.standardSeconds(60) (at minimum) or derive the timeout from feature/config inputs (e.g., readiness attempt budget) so the agent-side behavior stays aligned with the server-side orchestration settings.

Pull request overview

Copilot reviewed 108 out of 109 changed files in this pull request and generated no new comments.

Previously missed (1) — in code that hasn't changed since the last review.

engine/schema/src/main/resources/META-INF/db/schema-42210to42300.sql:707

• instance_boot_group_readiness_rule_details is being modeled as a ResourceDetailsDaoBase detail table, but the schema omits the usual display column. This means callers that use the inherited ResourceDetailsDao APIs that filter by display (e.g. listDetailsKeyPairs(resourceId, forDisplay) / findDetails(..., display)) can fail or behave incorrectly, and it also removes the ability to hide non-displayable values consistently.

Consider adding a display tinyint(1) column (default 1) to this table and mapping it in InstanceBootGroupReadinessRuleDetailsVO (instead of hardcoding isDisplay() to true), or alternatively avoid extending ResourceDetailsDaoBase for this entity and provide a DAO that doesn't rely on display.

Pull request overview

Copilot reviewed 118 out of 119 changed files in this pull request and generated 7 comments.

ui/src/views/compute/UpdateInstanceBootGroupMemberOrder.vue:1

• handleSubmit assumes it always receives a DOM event and calls preventDefault(), but <a-form @finish> in ant-design-vue passes form values (or nothing), not an event. This will throw at runtime when submitting via the form finish handler. Fix by either (a) splitting into handleFinish(values) for @finish and handleClick(event) for the button, or (b) guarding: only call preventDefault() when e?.preventDefault exists.
  ui/src/views/compute/UpdateInstanceBootGroupMemberOrder.vue:1
• The component mixes Options API with Composition API refs in a way that likely prevents the form ref from being wired reliably: formRef is created dynamically in initForm() (not declared in data()) and the template uses :ref=\"formRef\" rather than ref=\"formRef\". In Vue 3, undeclared instance properties are not reactive/proxied reliably and the template-ref binding may not populate this.formRef.value, causing this.formRef.value.validate() to fail intermittently. Prefer a single approach: either convert to setup() and return { formRef, form, rules, handleSubmit } with <a-form ref=\"formRef\">, or stay on Options API and use ref=\"formRef\" + this.$refs.formRef.
  ui/src/views/compute/UpdateInstanceBootGroupMemberOrder.vue:1
• The component mixes Options API with Composition API refs in a way that likely prevents the form ref from being wired reliably: formRef is created dynamically in initForm() (not declared in data()) and the template uses :ref=\"formRef\" rather than ref=\"formRef\". In Vue 3, undeclared instance properties are not reactive/proxied reliably and the template-ref binding may not populate this.formRef.value, causing this.formRef.value.validate() to fail intermittently. Prefer a single approach: either convert to setup() and return { formRef, form, rules, handleSubmit } with <a-form ref=\"formRef\">, or stay on Options API and use ref=\"formRef\" + this.$refs.formRef.
  engine/schema/src/main/java/com/cloud/vm/dao/InstanceBootGroupReadinessRuleDetailsDaoImpl.java:1
• If a caller stores a null value for the encrypted script key, DBEncryptionUtil.encrypt(value) may throw. Consider handling null explicitly (store null without encrypting) to avoid NPEs from unexpected/invalid input.
  engine/schema/src/main/java/com/cloud/vm/dao/InstanceBootGroupReadinessRuleDetailsDaoImpl.java:1
• DBEncryptionUtil.decrypt(value) is called unconditionally for the script key; if the stored value is null (or empty/unset due to earlier failures), decrypt may throw. Guard against null (and possibly blank) before decrypting so callers can still list rules without crashing.

Pull request overview

Copilot reviewed 118 out of 119 changed files in this pull request and generated 1 comment.

Pull request overview

Copilot reviewed 118 out of 119 changed files in this pull request and generated no new comments.

Previously missed (1) — in code that hasn't changed since the last review.

server/src/main/java/com/cloud/api/ApiResponseHelper.java:584

• The newly injected DAOs (instanceBootGroupDao, instanceBootGroupMemberDao, userVmDao, instanceGroupDao) are not referenced anywhere else in this class, so they add wiring/maintenance overhead without affecting behavior. Either use them in this PR (e.g. in boot-group response construction) or remove the unused injections until they’re needed.