Skip to content

Allow to customize how the proposal must handle pre-existing LVs in a reused VG#1421

Merged
ancorgs merged 9 commits intoyast:masterfrom
ancorgs:fix_reuse_vg
Mar 6, 2026
Merged

Allow to customize how the proposal must handle pre-existing LVs in a reused VG#1421
ancorgs merged 9 commits intoyast:masterfrom
ancorgs:fix_reuse_vg

Conversation

@ancorgs
Copy link
Copy Markdown
Contributor

@ancorgs ancorgs commented Feb 25, 2026

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 LvmCreator can delete LVs based on the value of Planned::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 LvmCreator more configurable. Then it will be able to either keep its original behavior (deleting LVs based on the value of Planned::LvmVg.make_space_policy) or to behave as Agama needs (resizing and deleting LVs based in the same configuration used by SpaceMaker).

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_name at Planned::LvmVg is not consistent with all the other classes at the Planned namespace.

Solution for that other problem

Fix how #assign_reuse identifies the volume group to be reused. That's much safer than changing the meaning of the internal @reuse_name variable (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 LvmCreator do 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

@ancorgs ancorgs changed the title Fix how volume groups are marked to be reused Allow to customize how the proposal must handle pre-existing LVs in a reusef VG Feb 27, 2026
@coveralls
Copy link
Copy Markdown

coveralls commented Mar 3, 2026

Coverage Status

coverage: 97.681% (-0.01%) from 97.692%
when pulling ac63913 on ancorgs:fix_reuse_vg
into d831b09 on yast:master.

@ancorgs ancorgs force-pushed the fix_reuse_vg branch 2 times, most recently from dfc9624 to e0cf4c4 Compare March 5, 2026 16:10
@ancorgs ancorgs marked this pull request as ready for review March 5, 2026 16:21
@ancorgs ancorgs changed the title Allow to customize how the proposal must handle pre-existing LVs in a reusef VG Allow to customize how the proposal must handle pre-existing LVs in a reused VG Mar 6, 2026
Copy link
Copy Markdown
Contributor

@joseivanlopez joseivanlopez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only some small things. BTW, isn't there any test for growing a volume group?

Comment thread src/lib/y2storage/proposal/lvm_space_strategies.rb Outdated
Comment thread src/lib/y2storage/proposal/lvm_space_maker.rb Outdated
Comment thread src/lib/y2storage/proposal/lvm_space_maker.rb
Comment thread src/lib/y2storage/proposal/lvm_creator.rb
Comment thread src/lib/y2storage/proposal/lvm_space_strategies/base.rb
Comment thread src/lib/y2storage/proposal/lvm_space_strategies/bigger_resize.rb Outdated
Comment thread src/lib/y2storage/proposal/lvm_space_strategies/bigger_resize.rb
Comment thread src/lib/y2storage/proposal/lvm_space_strategies/bigger_resize.rb
Comment thread src/lib/y2storage/proposal/lvm_space_strategies/auto.rb
Comment thread src/lib/y2storage/proposal/lvm_space_strategies/auto.rb Outdated
Copy link
Copy Markdown
Contributor

@joseivanlopez joseivanlopez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ancorgs ancorgs merged commit 37fb156 into yast:master Mar 6, 2026
8 of 11 checks passed
@github-actions
Copy link
Copy Markdown

github-actions Bot commented Mar 6, 2026

❌ Autosubmission job #22761970766 failed

@github-actions
Copy link
Copy Markdown

github-actions Bot commented Mar 6, 2026

✅ Autosubmission job #22761970766 successfully finished
✅ Created submit request #1337319

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).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants