Allow to customize how the proposal must handle pre-existing LVs in a reused VG#1421
Merged
ancorgs merged 9 commits intoyast:masterfrom Mar 6, 2026
Merged
Allow to customize how the proposal must handle pre-existing LVs in a reused VG#1421ancorgs merged 9 commits intoyast:masterfrom
ancorgs merged 9 commits intoyast:masterfrom
Conversation
dfc9624 to
e0cf4c4
Compare
Contributor
joseivanlopez
left a comment
There was a problem hiding this comment.
Only some small things. BTW, isn't there any test for growing a volume group?
|
❌ Autosubmission job #22761970766 failed |
|
✅ Autosubmission job #22761970766 successfully finished |
ancorgs
added a commit
to agama-project/agama
that referenced
this pull request
Mar 6, 2026
## Problem Agama does not allow to reuse an existing LVM volume group and its logical volumes. ## Solution This adds the possibility to search and, thus, reuse existing volume groups and its logical volumes. Includes the possibility to create normal volumes, thin pools and thin volumes. It also includes the possibility to create new thin volumes in a reused thin pool. It allows to specify which logical volumes should be deleted and resized in order to make space for the new logical volume, in a way totally analogous to what can already be done with partitions when using a disk. It also allows to add more physical volumes to an existing volume group. But only using explicit volumes (ie. physical volumes cannot be created on demand using `generate`). Apart from shrinking pre-existing logical volumes, this also allows to grow them in a similar way that what can be done for partitions. ## See also This depends on yast/yast-storage-ng#1421 ## Testing - Added unit tests, but they cannot pass until yast/yast-storage-ng#1421 is merged - Tested manually ## To do (follow-ups) - Detect possible incorrect settings or setups and detect them in the `ConfigChecker`. - More criteria for searching logical volumes, like searching by volume name or by volume type (normal, pool, thin, etc.). - Decide whether the proposal should refuse to resize some logical volumes and partitions to prevent unexpected data loss (that is a general topic not really related to LVM).
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.
Main problem
Agama does not allow to reuse an existing LVM volume group and its logical volumes. So we are adapting it to be able to do so. See agama-project/agama#3210
But as part of that implementation, we need the ability to decide what to do exactly with every pre-existing logical volume on the volume group (deleting, resizing, etc.) in the same way that similar actions can be specified for the partitions of any used disk.
The initial implementation for reusing LVM volume groups in Agama contains some logic to delete pre-existing logical volumes. The
LvmCreatorcan delete LVs based on the value ofPlanned::LvmVg.make_space_policy. But it cannot resize LVs and the behavior cannot be customized beyond the three possible values of the mentioned#make_space_policy(ie.:keep,:needed, and:resize).Solution
This implemens a solution to make
LvmCreatormore configurable. Then it will be able to either keep its original behavior (deleting LVs based on the value ofPlanned::LvmVg.make_space_policy) or to behave as Agama needs (resizing and deleting LVs based in the same configuration used bySpaceMaker).As in many other parts of the proposal code, this is achieved by using different strategy classes.
Another smaller problem
For some reason (maybe just a historical mistake), the usage of
#reuse_nameatPlanned::LvmVgis not consistent with all the other classes at thePlannednamespace.Solution for that other problem
Fix how
#assign_reuseidentifies the volume group to be reused. That's much safer than changing the meaning of the internal@reuse_namevariable (maybe there are good reasons to use that in a different way compared to other planned devices).Yet another smaller problem
During testing it was detected that
LvmCreatordo not create new thin volumes within a pre-existing (reused) thin pool. That affected the AutoYaST proposal and has the potential to affect the new features of the Agama proposal.Solution to that another smaller problem
This also includes a commit to fix the described problem, and its corresponding unit test.
Testing