Repository navigation
Conversation
…tostarting CLVM pools
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
Error handling, resource cleanup, and an existing failing test must be addressed.
4 open findings
What changed in this PR
Fixes CLVM/CLVM_NG pool deletion by handling inactive libvirt pools correctly.
Changes:
- Adds CLVM-specific pool deletion.
- Disables libvirt autostart for CLVM pools.
| File | Description |
|---|---|
ClvmStorageAdaptor.java |
Undefines CLVM pools without requiring activation. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| @@ -290,7 +326,6 @@ private StoragePool createCLVMStoragePool(Connect conn, String uuid, String host | |||
| try { | |||
| StoragePool pool = conn.storagePoolDefineXML(poolDef.toString(), 0); | |||
| logger.info("Created libvirt pool definition for CLVM/CLVM_NG VG: {} (pool will remain inactive)", volgroupName); | |||
| } | ||
| } | ||
|
|
||
| private boolean undefineInactiveClvmPool(Connect conn, String uuid) throws LibvirtException { |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #14379 +/- ##
=========================================
Coverage 20.21% 20.22%
- Complexity 20750 20759 +9
=========================================
Files 6426 6426
Lines 580181 580212 +31
Branches 71033 71038 +5
=========================================
+ Hits 117287 117333 +46
+ Misses 450180 450159 -21
- Partials 12714 12720 +6
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
🔴 Test Coverage Grade:
|
| Metric | Value |
|---|---|
| Line coverage | 25.19% |
| Branch coverage | 19.42% |
Grade Scale
| Grade | Line Coverage | Meaning |
|---|---|---|
| 🟢 A | ≥ 80% | Excellent - this code sleeps well at night 😴 |
| 🟡 B | 60-79% | Good - almost there, don't stop now 😉 |
| 🟠 C | 40-59% | Acceptable - your code is wearing a seatbelt, but no airbags 😬 |
| 🔴 D | 20-39% | Marginal - boldly shipping where no test has gone before 🖖 |
| ⛔ F | < 20% | Failing - tests? what tests? 🔥 |
Branch coverage is shown as a secondary signal. Grade is determined by line coverage.
View full Actions run
This branch has not been deployed
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: #14204
CLVM/CLVM_NG pools are deliberately kept inactive in libvirt, because LVM is driven directly with
vgs/lvs.ClvmStorageAdaptorhad nodeleteStoragePoolof its own, so it used the genericLibvirtStorageAdaptorversion. That version callsdestroy()on the pool, and libvirt rejectsdestroy()on an inactive pool. As a result, a CLVM pool could not be deleted, and enabling maintenance on it failed the same way.With this fix, deleting the pool in CloudStack only removes the CloudStack record and the libvirt pool definition on each host. It does not touch the volume group or the shared storage behind it. The VG, the lvmlockd/sanlock lockspace are left as they are, as CloudStack does not set any of these up. It only checks that the VG exists when the pool is added.
Tearing them down is the operator's responsibility, for example
vgchange --lockstop,vgremove, iSCSI logout and releasing the LUNs.Types of changes
Feature/Enhancement Scale or Bug Severity
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
Added a CLVM_NG/ CLVM pool
Put it in maintenance
Deleted the pool - Observed that the records were marked removed in the DB and the
virsh pool-list --allno longer showed the volume group.How did you try to break this feature and the system with this change?