server: report a domain's bucket, object storage and backup limits correctly by stag7824 · Pull Request #14293 · apache/cloudstack

stag7824 · 2026-10-02T08:44:11Z

Description

listDomains reports the bucket and object storage limits of every non-root domain as Unlimited, whatever has been configured. @ms30063600's re-test on #13944 shows it clearly: all 17 limits read back correctly from listResourceLimits, but the usage view (which reads listDomains) shows Bucket and Object Storage as Unlimited.

DomainJoinDaoImpl.setResourceLimits resolves those two types through the account helper:

long bucketLimit = ApiDBUtils.findCorrectResourceLimit(domain.getBucketLimit(), domain.getId(), ResourceType.bucket);
long objectStorageLimit = ApiDBUtils.findCorrectResourceLimit(domain.getObjectStorageLimit(), domain.getId(), ResourceType.object_storage);

findCorrectResourceLimit(limit, accountId, type) delegates to ResourceLimitManagerImpl.findCorrectResourceLimitForAccount, which first checks isRootAdmin(accountId) and then _accountDao.findById(accountId), returning unlimited for either. Passed a domain id, it is looking up an unrelated account — typically the root admin (account 2 vs. a domain with id 2) or nothing at all — so the configured limit is never reached. The other fifteen types in this method already use findCorrectResourceLimitForDomain; this changes the two outliers to match.

While in there, the backup rows had their unlimited checks copied from the row above:

String backupLimitDisplay = (fullView || snapshotLimit == -1) ? ...           // should be backupLimit
String backupAvail = (fullView || snapshotLimit == -1) ? ...                  // should be backupLimit
String backupStorageLimitDisplay = (fullView || backupLimit == -1) ? ...      // should be backupStorageLimit

so a domain with unlimited snapshots shows its backup limit as Unlimited, and one with unlimited backups shows its backup storage limit as Unlimited. AccountJoinDaoImpl does not have either problem.

Types of changes

Bug fix (non-breaking change which fixes an issue)

Feature/Enhancement Scale or Bug Severity

Bug Severity

Minor

How Has This Been Tested?

Added DomainJoinDaoImplTest, which calls setResourceLimits directly with ApiDBUtils stubbed (the domain lookup returns the domain's own limit; the account lookup returns unlimited, as it does in practice for a domain id) and verifies the values set on the response:

bucket 147 and object storage 157 GiB are reported as 147 / 157
backup 127 is reported while the snapshot limit is unlimited
backup storage 137 GiB is reported while the backup limit is unlimited

mvn test -pl server -Dtest=DomainJoinDaoImplTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0

Without the change to DomainJoinDaoImpl, all three fail. mvn checkstyle:check -pl server reports no violations.

I do not have a live environment to check the UI against, so this is unit-level; the reporter's JSON and screenshots on #13944 are the end-to-end reproduction.

One thing I could not explain from the code: the same screenshot shows VPC as "77 Available" but "0 / 67". Both values come from the same vpcLimit variable in this method, so that mismatch does not originate here and this PR does not address it.

…rrectly listDomains reported the bucket and object storage limits of every non-root domain as Unlimited, whatever was configured. DomainJoinDaoImpl resolved those two through ApiDBUtils.findCorrectResourceLimit, which is the account variant: it looks the id up in the account table. Given a domain id it finds either the root admin account or no account, and answers unlimited either way. The other fifteen resource types already go through findCorrectResourceLimitForDomain. The backup and backup storage rows had their unlimited checks copied from the row above: the backup limit was hidden whenever the snapshot limit was unlimited, and the backup storage limit whenever the backup limit was. listResourceLimits was never affected, which is why the values set through updateResourceLimit read back correctly there and only the usage view in the UI, which reads listDomains, showed them as Unlimited. Fixes apache#13944

rootnomad · 2026-10-09T20:37:43Z

Reproduced this on a 4.23 build and the change resolves it. On a non-root domain with the limits set through updateResourceLimit:

listResourceLimits reports them as configured: bucket 47, object_storage 57, backup 127, backup_storage 137
listDomains with details=resource, before the change, reports bucket, object storage and backup all as Unlimited

With this PR applied, the same listDomains call returns bucket 47, object storage 57, backup 127. The backup-storage gate is covered too: with the backup limit set to -1, backup storage keeps its own value instead of being pulled to Unlimited.

That lines up with both the account-vs-domain helper on the bucket and object-storage lines and the snapshot/backup mix-up in the backup rows.

stag7824 · 2026-10-11T17:30:28Z

For anyone looking at CI: the 8 workflow runs on the current head (59fb20a) have been waiting for approval since Oct 2, so nothing has run against this change yet. The unit tests were run locally (3 new tests, which fail without the change and pass with it; checkstyle clean), and @rootnomad's check above confirms the behaviour on a 4.23 build.

@DaanHoogland, since you were on #13944, could you or another committer approve the workflow runs? Thanks.

DaanHoogland · 2026-10-13T11:32:18Z

@blueorangutan package

blueorangutan · 2026-10-13T11:34:05Z

@DaanHoogland a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.

codecov · 2026-10-13T11:41:46Z

Codecov Report

❌ Patch coverage is 40.00000% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 18.01%. Comparing base (2e63c60) to head (59fb20a).
⚠️ Report is 15 commits behind head on 4.22.

Files with missing lines	Patch %	Lines
...ava/com/cloud/api/query/dao/DomainJoinDaoImpl.java	40.00%	0 Missing and 3 partials ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               4.22   #14293      +/-   ##
============================================
+ Coverage     18.00%   18.01%   +0.01%     
- Complexity    16219    16223       +4     
============================================
  Files          5936     5936              
  Lines        535716   535716              
  Branches      65596    65596              
============================================
+ Hits          96459    96517      +58     
+ Misses       428268   428161     -107     
- Partials      10989    11038      +49

Flag	Coverage Δ
uitests	`4.02% <ø> (ø)`
unittests	`19.09% <40.00%> (+0.01%)`	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Damans227 · 2026-10-13T12:14:56Z


        //get resource limits for buckets
-        long bucketLimit = ApiDBUtils.findCorrectResourceLimit(domain.getBucketLimit(), domain.getId(), ResourceType.bucket);
+        long bucketLimit = ApiDBUtils.findCorrectResourceLimitForDomain(domain.getBucketLimit(), ResourceType.bucket, domain.getId());


what happens if the domain has no bucket limit set? looks like the fallback only reads max.domain.buckets for storage types, so this still shows unlimited while creating stops at 20

Good catch, you're right. When a domain has no limit of its own, ApiDBUtils.findCorrectResourceLimitForDomain(Long, ResourceType, long) fell back to findDefaultResourceLimitForDomain, which only applies the max.domain.* default to storage types and returns unlimited for everything else, while enforcement uses ResourceLimitService.findCorrectResourceLimitForDomain (parent domain's limit, then the default). So it wasn't only buckets: IPs, volumes, snapshots, networks, CPU and memory showed unlimited the same way; VMs looked right because they already go through the other overload.

I've pushed a change (8f6592a) so that fallback uses the same lookup as enforcement, with a unit test that fails without it (expected:<20> but was:<-1>). One thing to be aware of: this means a domain without its own limits will now show the inherited or default limits for those types instead of "Unlimited", which is what's actually enforced.

that covers it

blueorangutan · 2026-10-13T12:44:00Z

Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 19532

… own When a domain has no limit set, the domain response fell back to findDefaultResourceLimitForDomain, which only reads the max.domain.* default for storage types and answers unlimited for the rest. Creating a resource still stops at the default (or at a parent domain's limit), so for example the bucket limit showed unlimited while bucket creation stopped at 20. Use the same lookup that is enforced.

stag7824 mentioned this pull request Oct 2, 2026

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

Open

Damans227 reviewed Oct 13, 2026

View reviewed changes

Navigation Menu

Repository navigation

server: report a domain's bucket, object storage and backup limits correctly - #14293

server: report a domain's bucket, object storage and backup limits correctly#14293
stag7824 wants to merge 2 commits into
apache:4.22from
stag7824:fix-domain-bucket-objectstorage-limits

stag7824 commented Oct 2, 2026

Uh oh!

rootnomad commented Oct 9, 2026

Uh oh!

stag7824 commented Oct 11, 2026

Uh oh!

DaanHoogland commented Oct 13, 2026

Uh oh!

blueorangutan commented Oct 13, 2026

Uh oh!

codecov Bot commented Oct 13, 2026 •

edited

Loading

Uh oh!

Damans227 Oct 13, 2026

Uh oh!

stag7824 Oct 13, 2026

Uh oh!

Damans227 Oct 14, 2026

Uh oh!

blueorangutan commented Oct 13, 2026

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Conversation

stag7824 commented Oct 2, 2026

Description

Types of changes

Feature/Enhancement Scale or Bug Severity

Bug Severity

How Has This Been Tested?

Uh oh!

rootnomad commented Oct 9, 2026

Uh oh!

stag7824 commented Oct 11, 2026

Uh oh!

DaanHoogland commented Oct 13, 2026

Uh oh!

blueorangutan commented Oct 13, 2026

Uh oh!

codecov Bot commented Oct 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Damans227 Oct 13, 2026

Choose a reason for hiding this comment

Uh oh!

stag7824 Oct 13, 2026

Choose a reason for hiding this comment

Uh oh!

Damans227 Oct 14, 2026

Choose a reason for hiding this comment

Uh oh!

blueorangutan commented Oct 13, 2026

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

codecov Bot commented Oct 13, 2026 •

edited

Loading