Resize Volume form does not show current size and Custom IOPS by suryag1201 · Pull Request #14262 · apache/cloudstack

suryag1201 · 2026-09-29T07:23:33Z

Description

On Resize Volume, the form did not show the volume’s current size and Custom IOPS. It also used the first disk offering in the list, not the offering already attached to the volume. So the dialog often opened empty or with the wrong IOPS fields.

Fixes: #14261

Types of changes

Breaking change (fix or feature that would cause existing functionality to change)
New feature (non-breaking change which adds functionality)
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

Screenshots (if appropriate):

Before Fix:

After Fix:

How Has This Been Tested?

How did you try to break this feature and the system with this change?

Damans227 · 2026-10-13T13:31:24Z

    fetchData () {
      this.loading = true
+      if (this.resource.size != null) {
+        this.form.size = this.resource.size / (1024 * 1024 * 1024)


what happens when the volume isnt a whole number of gb, like a root disk from a 2.2 gb template? resize only takes whole numbers so hitting ok without touching the size looks like it fails

Thanks @Damans227 for reviewing this PR
Root and data disk sizes are entered in GB, and both parameters are LONG, so a fractional value is rejected before the VM or volume is created. For example:
deployVirtualMachine with rootdisksize=3.5 returns: Unable to execute API command deployvirtualmachine due to invalid value 3.5 for parameter rootdisksize
createVolume with size=5.6 returns: Unable to execute API command createvolume due to invalid value 5.6 for parameter size
resizeVolume.size is also a LONG in GB. A volume created through these calls therefore has a whole-GB size, and that is the value prefilled on Resize.

what about a root disk deployed without a size? it takes the template's size, so a 2.2 gb template still gives a 2.2 gb disk and ok fails on it

@Damans227 This is a very good observation for this particular use case. Had we represented the size fields consistently in bytes instead of displaying GB values in some places, it would have made it much easier to identify and address the issue effectively.

The current fix helps streamline the behaviour for the remaining scenarios where the size values are whole numbers rather than fractional values. However, the behaviour is still not fully correct even today. For example, if a user navigates to this screen and attempts to modify only the IOPS without providing a size value, the operation can still fail or behave unexpectedly.

What would you recommend as a more holistic solution to address this behaviour and ensure consistent handling across all size-related scenarios?

can we leave size out of the call when it wasnt changed? resize keeps the current size when none is sent, so a 2.2 gb disk and an iops only change would both work

Thanks @Damans227, So you are suggesting,
Leave 2.2 visible in the Size field. If the user does not change it, do not include that value in the submit. The current disk size is then left as it is, so a 2.2 GB disk and an IOPS-only change both succeed. If the user enters a new whole-GB size, send that value.

yes thats it. the new commit doesnt do this yet, the form still sends the size on ok, so a 2.2 gb disk still fails. a root disk on an offering with a fixed root size fails too, even if only iops changed

Damans227 · 2026-10-13T13:31:25Z

+        this.loading = false
+        return
+      }
      getAPI('listDiskOfferings', {


does this find the offering for a root disk? listing disk offerings skips the ones that belong to a compute offering, so the iops fields wont show there

Good catch, @Damans227 . I have made the code changes.
A root volume created from a compute offering comes back with serviceofferingid instead of diskofferingid. The resize form used to stop when diskofferingid was missing, so the Min and Max IOPS fields were never shown for that root disk.
The resize form no longer calls listDiskOfferings. The volume response now includes iscustomizediops from the volume's disk offering, including a compute-only offering. When that flag is true, the form shows the Min and Max IOPS fields and prefills them from the volume.

thanks, this looks right for the root disk iops fields

nvazquez · 2026-10-30T01:52:01Z

Hi @suryag1201 @Damans227 are the review comments addressed or still some work is pending?

github-actions · 2026-10-30T16:12:44Z

This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch.

suryag1201 · 2026-10-30T16:14:05Z

Hi @suryag1201 @Damans227 are the review comments addressed or still some work is pending?

@nvazquez I have addressed the review comments now and updated the PR accordingly. There is still one ongoing discussion around resize volume behavior. I will incorporate any additional changes if required based on the outcome of those discussions.

### Description On Resize Volume, the form did not show the volume’s current size and IOPS. It also used the first disk offering in the list, not the offering already attached to the volume. So the dialog often opened empty or with the wrong IOPS fields, and a resize could send the wrong values. Root cause Three UI issues in fetchData(): Size unit — the API stores size in bytes. The form label is GB. Size was never copied onto the form, so the GB field stayed empty. Wrong offering — the code always used this.offerings[0] (first offering returned by listDiskOfferings), not this.resource.diskofferingid (the volume’s offering). Custom size / custom IOPS flags could be wrong. IOPS not filled — even when min/max IOPS existed on the volume, they were not copied into form.miniops / form.maxiops. Steps to reproduce Create a volume with a custom IOPS disk offering (for example min 2000, max 5000) and a known size (for example 20 GB). Open Storage → Volumes → Resize. Check the Size (GB) field and the Min/Max IOPS fields.           ### Types of changes - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [ ] 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 - [ ] Major - [ ] Minor - [ ] Trivial ### Screenshots (if appropriate): Before Fix: <img width="533" height="353" alt="image" src="https://github.com/user-attachments/assets/ccfc698e-501c-442e-a7b2-9582dc2a53ba" /> After Fix: <img width="528" height="472" alt="image" src="https://github.com/user-attachments/assets/5125bb21-9b9b-4e48-a9bc-8d5eaef07118" /> ### How Has This Been Tested? Tested with both Fix and Custom IOPS: 1- Resize Shows IOPS value for custom IOPS not for fix, along with size 2- Exact 20 GB volume → shows as 20 float 20.1 -> shows on UI as 20 #### How did you try to break this feature and the system with this change?   --------- Co-authored-by: Gupta, Surya <Surya.Gupta@netapp.com>

Root Volume created with custom IOPS and not overridden by the custom disk offering should also show the min and max IOPS on form     - [ ] 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) - [x] Major - [ ] Minor - [ ] BLOCKER - [ ] Critical - [x] Major - [ ] Minor - [ ] Trivial <img width="655" height="529" alt="image" src="https://github.com/user-attachments/assets/335b1c6c-e979-4976-a7a3-1c1b52f535e7" /> <img width="526" height="407" alt="image" src="https://github.com/user-attachments/assets/76a5e0e5-ec23-4b0f-96ea-ee43c81cfa44" /> <img width="599" height="460" alt="image" src="https://github.com/user-attachments/assets/923c44a5-b53f-452f-944c-73ef3c75d804" /> 1- Created a Fix IOPS Offering of compute/disk and use to create VM/Volume, resize should not show min max IOPS - success 2- Created a Custom IOPS Offering of compute/disk and use to create VM/Volume, resize should show min max IOPS - success change?   --------- Co-authored-by: Gupta, Surya <Surya.Gupta@netapp.com>

Damans227 · 2026-10-30T16:33:57Z

@nvazquez not yet. the root disk iops part looks fixed, but the form still sends the size when it isnt changed, so a 2.2 gb disk still fails. theres also a merge conflict in the test file for @suryag1201 to fix

boring-cyborg Bot added the component:UI label Sep 29, 2026

suryag1201 mentioned this pull request Oct 6, 2026

Custom IOPS not applied to root disk when deploying a VM from a template #14103

Open

nvazquez added this to the 4.22.2 milestone Oct 8, 2026

nvazquez added the type:bug label Oct 8, 2026

nvazquez modified the milestones: 4.22.2, 24.0 Oct 8, 2026

Damans227 reviewed Oct 13, 2026

View reviewed changes

nvazquez mentioned this pull request Oct 30, 2026

Resize Volume form does not show current size and Custom IOPS #14261

Open

boring-cyborg Bot added the component:api label Oct 30, 2026

github-actions Bot added the status:has-conflicts label Oct 30, 2026

suryag1201 and others added 2 commits October 30, 2026 22:03

suryag1201 force-pushed the resize-volume-form-issue branch from cf05c06 to c2c30e8 Compare October 30, 2026 16:34

github-actions Bot removed the status:has-conflicts label Oct 30, 2026

Conversation

suryag1201 commented Sep 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Types of changes

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

Bug Severity

Screenshots (if appropriate):

How Has This Been Tested?

How did you try to break this feature and the system with this change?

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

suryag1201 Oct 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nvazquez commented Oct 30, 2026

Uh oh!

github-actions Bot commented Oct 30, 2026

Uh oh!

suryag1201 commented Oct 30, 2026

Uh oh!

Damans227 commented Oct 30, 2026

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

suryag1201 commented Sep 29, 2026 •

edited

Loading

suryag1201 Oct 30, 2026 •

edited

Loading