Fix for listCapacity with fetchlatest parameter causing RuntimeException #12421
+2
−7
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## 4.20 #12421 +/- ##
============================================
+ Coverage 16.23% 17.76% +1.52%
- Complexity 13378 15863 +2485
============================================
Files 5657 5923 +266
Lines 498866 530603 +31737
Branches 60545 64835 +4290
============================================
+ Hits 81011 94273 +13262
- Misses 408821 425783 +16962
- Partials 9034 10547 +1513
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Collaborator
Author
|
@blueorangutan package |
|
@abh1sar 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. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 16357 |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes a RuntimeException that occurs when using the listCapacity API with the fetchlatest parameter. The issue is caused by nested transaction handling when updateCapacityForHost (which has the @DB annotation and manages its own transactions) is wrapped in an additional Transaction.execute block within a multi-threaded executor context.
Changes:
- Removed redundant
Transaction.executewrapper aroundupdateCapacityForHostcall inrecalculateHostCapacities() - Simplified the code by calling
updateCapacityForHostdirectly, relying on its@DBannotation for transaction management
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+297
to
+298
| final HostVO host = hostDao.findById(hostId); | ||
| _capacityMgr.updateCapacityForHost(host); |
There was a problem hiding this comment.
The change correctly removes the redundant Transaction.execute wrapper. However, there's an inconsistency with recalculateStorageCapacities() (lines 313-347) which still uses Transaction.execute wrapper. For consistency and to prevent similar nested transaction issues, consider applying the same pattern if the methods called within have their own transaction management (e.g., if they use @db annotation or Transaction.execute internally).
RosiKyu
approved these changes
Jan 14, 2026
Collaborator
RosiKyu
left a comment
RosiKyu
left a comment
There was a problem hiding this comment.
LGTM
Screencast.from.2026-01-14.16-55-55.webm
Test steps:
- Ran list capacity fetchlatest=true via CloudMonkey
- Clicked "Fetch latest" button in UI Dashboard → Storage widget
- Checked management server logs for RuntimeException
Results:
- API returns capacity data successfully
- No NO EVENT PUBLISH CAN BE WRAPPED WITHIN DB TRANSACTION exception in logs
- Capacity values update correctly after VM start/stop operations (verified MEMORY went from 11% → 41%, CPU_CORE from 25% → 87.5% after starting VMs)
Initial State
(localcloud) 🐱 > list capacity fetchlatest=true
{
"capacity": [
{
"capacityallocated": 1610612736,
"capacitytotal": 14491254784,
"capacityused": 1610612736,
"name": "MEMORY",
"percentused": "11.11",
"type": 0,
"zoneid": "e0fdc65b-a0b1-4bad-ace4-0037a33b0d81",
"zonename": "ref-trl-6148-k-Mol9-rositsa-kyuchukova"
},
{
"capacityallocated": 1000,
"capacitytotal": 37600,
"capacityused": 1000,
"name": "CPU",
"percentused": "2.66",
"type": 1,
"zoneid": "e0fdc65b-a0b1-4bad-ace4-0037a33b0d81",
"zonename": "ref-trl-6148-k-Mol9-rositsa-kyuchukova"
},
{
"capacitytotal": 2111479742464,
"capacityused": 1449457090560,
"name": "STORAGE",
"percentused": "68.65",
"type": 2,
"zoneid": "e0fdc65b-a0b1-4bad-ace4-0037a33b0d81",
"zonename": "ref-trl-6148-k-Mol9-rositsa-kyuchukova"
},
{
"capacitytotal": 4222959484928,
"capacityused": 10485956688,
"name": "STORAGE_ALLOCATED",
"percentused": "0.25",
"type": 3,
"zoneid": "e0fdc65b-a0b1-4bad-ace4-0037a33b0d81",
"zonename": "ref-trl-6148-k-Mol9-rositsa-kyuchukova"
},
{
"capacitytotal": 20,
"capacityused": 2,
"name": "VIRTUAL_NETWORK_PUBLIC_IP",
"percentused": "10",
"type": 4,
"zoneid": "e0fdc65b-a0b1-4bad-ace4-0037a33b0d81",
"zonename": "ref-trl-6148-k-Mol9-rositsa-kyuchukova"
},
{
"capacitytotal": 20,
"capacityused": 2,
"name": "PRIVATE_IP",
"percentused": "10",
"type": 5,
"zoneid": "e0fdc65b-a0b1-4bad-ace4-0037a33b0d81",
"zonename": "ref-trl-6148-k-Mol9-rositsa-kyuchukova"
},
{
"capacitytotal": 1055739871232,
"capacityused": 724728545280,
"name": "SECONDARY_STORAGE",
"percentused": "68.65",
"type": 6,
"zoneid": "e0fdc65b-a0b1-4bad-ace4-0037a33b0d81",
"zonename": "ref-trl-6148-k-Mol9-rositsa-kyuchukova"
},
{
"capacitytotal": 20,
"capacityused": 0,
"name": "VLAN",
"percentused": "0",
"type": 7,
"zoneid": "e0fdc65b-a0b1-4bad-ace4-0037a33b0d81",
"zonename": "ref-trl-6148-k-Mol9-rositsa-kyuchukova"
},
{
"capacitytotal": 0,
"capacityused": 0,
"name": "GPU",
"percentused": "0",
"type": 19,
"zoneid": "e0fdc65b-a0b1-4bad-ace4-0037a33b0d81",
"zonename": "ref-trl-6148-k-Mol9-rositsa-kyuchukova"
},
{
"capacityallocated": 2,
"capacitytotal": 8,
"capacityused": 2,
"name": "CPU_CORE",
"percentused": "25",
"type": 90,
"zoneid": "e0fdc65b-a0b1-4bad-ace4-0037a33b0d81",
"zonename": "ref-trl-6148-k-Mol9-rositsa-kyuchukova"
}
],
"count": 10
}
After deploying VMs - recalc
(localcloud) 🐱 > list capacity fetchlatest=true
{
"capacity": [
{
"capacityallocated": 5905580032,
"capacitytotal": 14491254784,
"capacityused": 5905580032,
"name": "MEMORY",
"percentused": "40.75",
"type": 0,
"zoneid": "e0fdc65b-a0b1-4bad-ace4-0037a33b0d81",
"zonename": "ref-trl-6148-k-Mol9-rositsa-kyuchukova"
},
{
"capacityallocated": 5000,
"capacitytotal": 37600,
"capacityused": 5000,
"name": "CPU",
"percentused": "13.3",
"type": 1,
"zoneid": "e0fdc65b-a0b1-4bad-ace4-0037a33b0d81",
"zonename": "ref-trl-6148-k-Mol9-rositsa-kyuchukova"
},
{
"capacitytotal": 2111479742464,
"capacityused": 1457191387136,
"name": "STORAGE",
"percentused": "69.01",
"type": 2,
"zoneid": "e0fdc65b-a0b1-4bad-ace4-0037a33b0d81",
"zonename": "ref-trl-6148-k-Mol9-rositsa-kyuchukova"
},
{
"capacitytotal": 4222959484928,
"capacityused": 200412823888,
"name": "STORAGE_ALLOCATED",
"percentused": "4.75",
"type": 3,
"zoneid": "e0fdc65b-a0b1-4bad-ace4-0037a33b0d81",
"zonename": "ref-trl-6148-k-Mol9-rositsa-kyuchukova"
},
{
"capacitytotal": 20,
"capacityused": 3,
"name": "VIRTUAL_NETWORK_PUBLIC_IP",
"percentused": "15",
"type": 4,
"zoneid": "e0fdc65b-a0b1-4bad-ace4-0037a33b0d81",
"zonename": "ref-trl-6148-k-Mol9-rositsa-kyuchukova"
},
{
"capacitytotal": 20,
"capacityused": 2,
"name": "PRIVATE_IP",
"percentused": "10",
"type": 5,
"zoneid": "e0fdc65b-a0b1-4bad-ace4-0037a33b0d81",
"zonename": "ref-trl-6148-k-Mol9-rositsa-kyuchukova"
},
{
"capacitytotal": 1055739871232,
"capacityused": 728595693568,
"name": "SECONDARY_STORAGE",
"percentused": "69.01",
"type": 6,
"zoneid": "e0fdc65b-a0b1-4bad-ace4-0037a33b0d81",
"zonename": "ref-trl-6148-k-Mol9-rositsa-kyuchukova"
},
{
"capacitytotal": 20,
"capacityused": 1,
"name": "VLAN",
"percentused": "5",
"type": 7,
"zoneid": "e0fdc65b-a0b1-4bad-ace4-0037a33b0d81",
"zonename": "ref-trl-6148-k-Mol9-rositsa-kyuchukova"
},
{
"capacitytotal": 0,
"capacityused": 0,
"name": "GPU",
"percentused": "0",
"type": 19,
"zoneid": "e0fdc65b-a0b1-4bad-ace4-0037a33b0d81",
"zonename": "ref-trl-6148-k-Mol9-rositsa-kyuchukova"
},
{
"capacityallocated": 7,
"capacitytotal": 8,
"capacityused": 7,
"name": "CPU_CORE",
"percentused": "87.5",
"type": 90,
"zoneid": "e0fdc65b-a0b1-4bad-ace4-0037a33b0d81",
"zonename": "ref-trl-6148-k-Mol9-rositsa-kyuchukova"
}
],
"count": 10
}
RosiKyu
added
status:ready-for-merge
and removed
status:testing
status:needs-testing
labels
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR fixes #12397
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
Tested listCapacity api with fetchlatest parameter. No exceptions were observed.
Tested with the
Fetch Latestbutton on the capacity dashboard. Capacities were lister correctly.How did you try to break this feature and the system with this change?