yuminn-k opened a new pull request, #14606: URL: https://github.com/apache/cloudstack/pull/14606
### Description This PR fixes the deploy instance wizard sending `deployVirtualMachine` without `rootdisksize` when the auto-selected compute offering links a disk offering with a custom size. The API then rejects the request with error 431, "This disk offering requires a custom size specified". Fixes: #14524 Evidence tags: **[code]** = read at a permalink, **[executed]** = run locally, **[inference]** = reasoning I did not run. **Root cause** 1. With the default (OS based) image selection, the template list auto-selects the first image and emits it twice: once from the `imagesList` watcher (`onClickRow`), and again from the `selected` watcher when the parent passes the id back. **[code]** https://github.com/apache/cloudstack/blob/d02adcde9008729c55e648c4bbbd861097aa33bb/ui/src/views/compute/wizard/OsBasedImageRadioGroup.vue#L146-L184 **[executed]** see the trace below 2. Each emit calls `updateFieldValue('templateid', id)`, which calls `resetFromTemplateConfiguration()`. That method deletes `rootdisksize` from `instanceConfig`, which is the same object as the form. **[code]** https://github.com/apache/cloudstack/blob/d02adcde9008729c55e648c4bbbd861097aa33bb/ui/src/views/compute/DeployVM.vue#L2039-L2045 and https://github.com/apache/cloudstack/blob/d02adcde9008729c55e648c4bbbd861097aa33bb/ui/src/views/compute/DeployVM.vue#L3289-L3290 3. The root `DiskSizeSelection` emits its value on mount and when `minDiskSize` changes. For the second emit of the same template, `minrootdisksize` does not change, so the size is not emitted again. **[code]** https://github.com/apache/cloudstack/blob/d02adcde9008729c55e648c4bbbd861097aa33bb/ui/src/views/compute/wizard/DiskSizeSelection.vue#L80-L117 4. At submit, `rootdisksize` is only added when the form has it. **[code]** https://github.com/apache/cloudstack/blob/d02adcde9008729c55e648c4bbbd861097aa33bb/ui/src/views/compute/DeployVM.vue#L2407-L2412 This only happens when the compute offering, and with it the size input, is already in place before the template is selected. That is the case when the first offering is auto-selected. Switching to another offering and back remounts `DiskSizeSelection`, which emits the size again. This matches the workaround in the issue. **[inference]**, consistent with the trace below. **Change** `updateFieldValue('templateid', id)` now keeps `form.rootdisksize` when the selected template does not change. Selecting a different template still clears it, as before. ### Types of changes - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [x] Bug fix (non-breaking change which fixes an issue) - [ ] Enhancement (improves an existing feature and functionality) - [ ] Cleanup (Code refactoring and cleanup, that may add test cases) - [ ] Build/CI - [ ] Test (unit or integration test code) ### Feature/Enhancement Scale or Bug Severity #### Feature/Enhancement Scale - [ ] Major - [ ] Minor #### Bug Severity - [ ] BLOCKER - [ ] Critical - [x] Major - [ ] Minor - [ ] Trivial ### Screenshots (if appropriate): ### How Has This Been Tested? - **[executed]** New unit test `ui/tests/unit/views/compute/DeployVMRootDiskSize.spec.js`. "keeps the root disk size when the same template is selected again" fails without the change (`Expected: 8, Received: undefined`) and passes with it. "clears the root disk size when another template is selected" passes both before and after. - **[executed]** `npm run test:unit` on 4.22 with this change: 195 of 196 pass. The one failure is `UsageRecords.spec.js` (the daylight-saving end date case). It also fails without this change, so it is not caused by this PR. - **[executed]** `vue-cli-service lint --no-fix` on the changed files: no errors. - **[executed]** Local trace, not part of this PR: I mounted the real `DeployVM.vue` in jest with mocked API responses for one zone, one 8 GB template, one compute offering linked to a custom size disk offering, and the default image selection. Without the change, the call order was `updateFieldValue("rootdisksize", 8)`, `updateFieldValue("templateid", "t1")`, then `resetFromTemplateConfiguration()`, and the result was a form without `rootdisksize` and an empty disk size in the summary. With the change, the form keeps `rootdisksize: 8` and the summary shows `8 GB (Root)`. The same harness with the legacy image selection, or with the compute offerings loading after the template, already had the size before the change. - Not done: I did not deploy an instance against a running management server. Manual check: 1. Create a disk offering with custom disk size. 2. Create a compute offering with "Compute only disk offering" disabled, linked to that disk offering, and make it the first offering in the list. 3. Open Add Instance, pick a zone and let the first image and offering be auto-selected. Enter a name and launch. 4. Before: the summary has no root disk size and the API returns 431. After: the summary shows the template size and the request has `rootdisksize`. #### How did you try to break this feature and the system with this change? - Selecting a different template still clears the root disk size (covered by the second test). The new template's size then comes from `DiskSizeSelection` through the changed `minrootdisksize`. - The size is only kept when the template id is unchanged. ISO, volume and snapshot selection are not touched. - The change applies cleanly to `main`. Assisted-by: Claude Opus 5.5 (Claude Code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
