Repository navigation
Resize Volume form does not show current size and Custom IOPS - #14262
suryag1201 wants to merge 1 commit into
Conversation
### 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. <!--- Describe your changes in DETAIL - And how has behaviour functionally changed. --> <!-- For new features, provide link to FS, dev ML discussion etc. --> <!-- In case of bug fix, the expected and actual behaviours, steps to reproduce. --> <!-- When "Fixes: #<id>" is specified, the issue/PR will automatically be closed when this PR gets merged --> <!-- For addressing multiple issues/PRs, use multiple "Fixes: #<id>" --> <!-- Fixes: # --> <!--- ******************************************************************************* --> <!--- NOTE: AUTOMATION USES THE DESCRIPTIONS TO SET LABELS AND PRODUCE DOCUMENTATION. --> <!--- PLEASE PUT AN 'X' in only **ONE** box --> <!--- ******************************************************************************* --> ### 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? <!-- see how your change affects other areas of the code, etc. --> <!-- Please read the [CONTRIBUTING](https://github.com/apache/cloudstack/blob/main/CONTRIBUTING.md) document --> --------- Co-authored-by: Gupta, Surya <Surya.Gupta@netapp.com>
| fetchData () { | ||
| this.loading = true | ||
| if (this.resource.size != null) { | ||
| this.form.size = this.resource.size / (1024 * 1024 * 1024) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
| this.loading = false | ||
| return | ||
| } | ||
| getAPI('listDiskOfferings', { |
There was a problem hiding this comment.
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
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
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
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?