[UI BUG] Resource limits for type 15 (ObjectStorage) and 16 (GPU) do not sync/display correctly in Web UI #13944

Thanks for opening your first issue here! Be sure to follow the issue template!

@ms30063600 / Maurice, the UI is behind the API in principle. Some people feel you should implement immediately in the UI what you implement in the API. I could agree less. Or actually couldn’t oppose more. The API is prone to PoC and shouldn’t be sold as clickable bait in my not so humble opinion. However, and more specific to you example, feel free to implement UI changes that reflect the current state of this particular API if you feel you need it. Object Storage and GPU are latecomers though not entirely new any more.

@abh1sar @vishesh92 , maybe you guys have more inviting ideas on this?

I had a look at this. I could not reproduce it for resource types 15 and 16 specifically, and I think the diagnosis in the report is off — though there is a real gap next door.

ResourceLimitTab.vue builds the limits panel entirely from what listResourceLimits returns; there is no hardcoded list of types to filter against. Each label is looked up as:

$t('label.max' + item.resourcetypename.replace('_', ''))

For 15 and 16 that resolves to label.maxobjectstorage and label.maxgpu, and both are present in en.json ("Max. Object Storage (GiB)" and "Max. GPUs"). Resolving all 17 Resource.ResourceType values through that expression against the real locale file, the only one that misses is type 12, backup → label.maxbackup, which exists in no locale. That row renders the raw key. I've opened #14163 for it.

Two things that may actually be behind what you saw, @ms30063600 — both worth checking against your setup:

1. Storage types are converted to GiB on the way out. ApiResponseHelper.createResourceLimitResponse divides by bytesToGiB and rounds up for every type where ResourceType.isStorageType is true, which includes object_storage (15). So a limit set in bytes via updateResourceLimit comes back in GiB in listResourceLimits, and the UI shows the GiB figure. Values under 1 GiB round up to 1. GPU (16) is not a storage type and is not converted. If the number you set and the number displayed differ by a factor of ~2^30, that's this.

2. A limit of 0 displays as Unlimited. In fetchData, tagged limits are read as subItem.max || -1, so a stored 0 becomes -1. Untagged limits get corrected a few lines later by form[item.resourcetype] = item.max == null ? -1 : item.max, but tagged ones do not, and origValues is only recorded for the untagged entry — so a tagged limit of 0 both displays as Unlimited and is written back as -1 on the next save. That one looks like a genuine bug to me, separate from the label. Happy to raise it separately if it isn't already known.

Could you say which values you set for 15 and 16, and whether the rows were tagged? That would tell us which of these you hit.

Hi @stag7824
I read your reaction last night. Let me perform a re-test, see below.
For this test I use the https://qa.cloudstack.cloud environment.
My test domain is "Domain2" with id="daaee52a-cb7a-4206-a862-6219e7341426". As far as I know the resource limits are reset daily.
Step 1: Show current resource limit values: see attached file result_demo_listResourceLimits_20260916-071214-172493.json.
Step 2: Update each resource limit for this domain (17 requests). The value that I set is: resourceid * 10 + 7. Done.
Step 3: Show current resource limit values run after step 2: see attached file result_demo_listResourceLimits_20260916-074146-360675.json.
This shows that the resource limits have the following values (excerpt taken from the json result file).
"resourcetype": "0",
"max": 7
"resourcetype": "1",
"max": 17
"resourcetype": "2",
"max": 27
"resourcetype": "3",
"max": 37
"resourcetype": "4",
"max": 47
"resourcetype": "5",
"max": 57
"resourcetype": "6",
"max": 67
"resourcetype": "7",
"max": 77
"resourcetype": "8",
"max": 87
"resourcetype": "9",
"max": 97
"resourcetype": "10",
"max": 107
"resourcetype": "11",
"max": 117
"resourcetype": "12",
"max": 127
"resourcetype": "13",
"max": 137
"resourcetype": "14",
"max": 147
"resourcetype": "15",
"max": 157
"resourcetype": "16",
"max": 167

Final step: compare with gui. To this end I supply two screenshots (note "Secondary storage limit" is in both, so you can see that I did not miss a single resource).
Please check that the various values are indeed in the screenshot. Also it appears here that the resource limits are shown in a different order than by increasing resourceid. Please check that the last two lines of the second screenshot that the limit is still "Unlimited". I expected to see there 157 and 167.

Kind regards,
Mau

result_demo_listResourceLimits_20260916-071214-172493.json

result_demo_listResourceLimits_20260916-074146-360675.json

Thank you for the careful re-test, @ms30063600 — you were right and I was looking in the wrong place. My earlier note was about the Resource Limits edit tab; your screenshots are the usage view, which reads its values from listDomains rather than listResourceLimits, and that is where the bug is.

DomainJoinDaoImpl resolved the bucket and object storage limits through the account helper, ApiDBUtils.findCorrectResourceLimit, passing it the domain's id. That looks the id up in the account table, finds the root admin or nothing, and answers unlimited either way — so the configured value was never used. Every other resource type there already used the domain helper. One small correction to the report: in your screenshot the unlimited rows are Bucket (14) and Object Storage (15); GPU (16) shows 167 correctly.

There were also copy-paste mistakes in the backup rows (the backup limit was hidden whenever snapshots were unlimited, and backup storage whenever backups were). Your test didn't hit those because every limit was set, but they would show up on a domain with some limits left unlimited.

All three are fixed in #14293, with tests.

I still can't explain the VPC row in your first screenshot ("77 Available" but "0 / 67") — both numbers come from the same variable in this code, so it isn't from here. If you can reproduce it, the raw listDomains response for that domain would show whether vpclimit really comes back as 67.

Hi @stag7824,
I could not respond earlier.
Thanks for the fix. Thanks for pointing out the flaw in my report. I agree that the VPC row is indeed odd. Do you still observe this after your fix?
Kind regards, Mau.