Skip to content

snapm: snapshot set resize fixes#490

Merged
bmr-cymru merged 10 commits intomainfrom
bmr-resize-fixes
Sep 24, 2025
Merged

snapm: snapshot set resize fixes#490
bmr-cymru merged 10 commits intomainfrom
bmr-resize-fixes

Conversation

@bmr-cymru
Copy link
Copy Markdown
Contributor

@bmr-cymru bmr-cymru commented Sep 24, 2025

Fixes for the lvm2cow plugin resize ops, resize logging enhancements to Manager and SnapshotSet and doc change to note the limitations of "resize" for CoW volumes. Additionally include fixes for Rust toolchain updates that break the stratisd build and a minor optimization to git clone operations.

Resolves: #150
Resolves: #151
Resolves: #152
Resolves: #482
Resolves: #483
Resolves: #484
Resolves: #486
Resolves: #487
Resolves: #488
Resolves: #489
Resolves: #491
Resolves: #492

Summary by CodeRabbit

  • New Features

    • Snapshot sizing now aligns to volume-group extent boundaries to avoid unnecessary resizes.
  • Bug Fixes

    • Prevents shrinking of LVM2 copy-on-write snapshots (not supported).
    • More accurate free-space validation with clearer, user-facing error messages when space is insufficient.
  • Improvements

    • Skips no-op resize operations and logs the decision.
    • Enhanced diagnostic logging of per-provider sizing and free-space calculations.
  • Documentation

    • Man page clarified; reference to lvm2-cow and snapshot shrink limitation added.
  • Tests / Fixtures / CI

    • Added unit tests for extent rounding; updated test fixtures and CI checkout settings.

Resolves: #482

Signed-off-by: Bryn M. Reeves <bmr@redhat.com>
Return a 2-tuple (vg_free, vg_extent_size) to allow rounding sizes to
extent boundaries.

Resolves: #483

Signed-off-by: Bryn M. Reeves <bmr@redhat.com>
@bmr-cymru bmr-cymru self-assigned this Sep 24, 2025
@bmr-cymru bmr-cymru added Bug Something isn't working Enhancement New feature or request UI/UX User interface and experience LVM2 labels Sep 24, 2025
@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Sep 24, 2025

Walkthrough

Updated LVM2 snapshot sizing and diagnostics: extent-size retrieval and rounding added, CoW snapshot shrinking explicitly rejected, debug logging added during create/resize flows, plugin APIs updated to return extent size, tests and manpage updated, and CI workflow adjusted.

Changes

Cohort / File(s) Summary of changes
Docs: man page
man/man8/snapm.8
Replaced hard-coded policy token with styled lvm2-cow, added note that lvm2-cow snapshots cannot be shrunk, and adjusted paragraph breaks.
Core logging: resize and manager
snapm/_snapm.py, snapm/manager/_manager.py
Added debug logging to emit per-provider transaction size_map during SnapshotSet.resize and in create_snapshot_set before suspending the journal; no functional or error-handling changes.
LVM2 plugin: extent rounding, VG extent, and resize behavior
snapm/manager/plugins/lvm2.py
Added _round_up_extents(size_bytes, extent_size); expanded VGS_FIELD_OPTIONS to include vg_extent_size; vg_free_space() now returns (vg_free, vg_extent_size); _check_free_space(origin, mount_point, size_policy, snapshot_name=None) updated to use extent rounding, compute needed space relative to existing LV size, prohibit CoW snapshot shrinking (raises SnapmNoSpaceError), and log detailed sizing/rounding info. Call sites updated; create_snapshot/resize_snapshot use computed sizes and avoid calling lvresize for no-op changes.
Tests: rounding and vgs fixtures
tests/test_lvm2.py, tests/bin/vgs
Added unit tests for _round_up_extents (normal, edge, and invalid inputs). Updated test_vg_free_space fixtures and tests/bin/vgs mock outputs to include (vg_free, vg_extent_size) tuples and adapted assertions.
CI workflow
.github/workflows/snapm.yml
Switched several git checkouts to shallow clones (--depth 1), pinned Rust toolchain to 1.85.0, and updated stratisd / stratis-cli checkout refs to specified branches.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  actor User
  participant Snapm as Snapm Core
  participant Manager
  participant LVM2Plugin as LVM2 Plugin
  participant LVM2 as LVM2 Tools

  User->>Snapm: request create/resize snapshot
  Snapm->>Manager: orchestrate snapshot operation
  Manager->>LVM2Plugin: _check_free_space(origin, mount_point, policy, snapshot_name?)
  LVM2Plugin->>LVM2: vgs --reportfields vg_name,vg_free,vg_extent_size
  LVM2-->>LVM2Plugin: (vg_free, vg_extent_size)
  LVM2Plugin->>LVM2Plugin: _round_up_extents(policy.size, vg_extent_size)
  LVM2Plugin->>LVM2Plugin: determine current_size if snapshot exists
  alt rounded_target < current_size
    LVM2Plugin-->>Manager: error (shrink not supported)
  else rounded_target == current_size
    LVM2Plugin-->>Manager: needed_space = 0 (no-op)
  else
    LVM2Plugin-->>Manager: needed_space = rounded_target - current_size (or rounded_target for new)
  end
  Manager->>Manager: debug-log provider/transaction size_map
  alt needed_space > 0
    Manager->>LVM2: lvresize -L+<size_change>
    LVM2-->>Manager: OK
    Manager-->>User: Done
  else needed_space == 0
    Manager-->>User: No-op / already sized
  end
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Suggested labels

documentation, Plugin Integration

Poem

I nibble extents and round each bite,
I log the maps before I spring to flight.
I refuse to shrink what once was cast,
If size-change is zero, I rest at last.
VG grains counted — tests hop in delight. 🐇✨

Pre-merge checks and finishing touches

✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check ✅ Passed The title "snapm: snapshot set resize fixes" is a concise, single-sentence summary that accurately highlights the primary focus of the changeset (resize-related fixes and related logging/behavior updates) and contains no extraneous noise or emojis, so a teammate scanning history can quickly understand the PR intent.
Out of Scope Changes Check ✅ Passed All changed files (lvm2 plugin, manager/SnapshotSet logging, tests and test fixtures, man page, and CI workflow) correspond to the stated objectives in the linked issues (resize fixes, rounding, logging, docs, and CI/tooling); I do not see unrelated or extraneous modifications outside those scopes.
Docstring Coverage ✅ Passed No functions found in the changes. Docstring coverage check skipped.
Linked Issues Check ✅ Passed The patch implements many linked objectives: it adds an extent-rounding helper with tests, updates LVM2 size-checking to compute rounded targets and reserve only the net additional space, detects and rejects CoW snapshot shrinking (with a man-page note), skips no-op lvresize calls, introduces debug logging in manager/SnapshotSet and lvm2 calculation paths, and applies CI/tooling changes to pin the Rust toolchain and use shallow clones.

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5c6f898 and 52eaf0c.

📒 Files selected for processing (7)
  • .github/workflows/snapm.yml (3 hunks)
  • man/man8/snapm.8 (1 hunks)
  • snapm/_snapm.py (1 hunks)
  • snapm/manager/_manager.py (1 hunks)
  • snapm/manager/plugins/lvm2.py (9 hunks)
  • tests/bin/vgs (4 hunks)
  • tests/test_lvm2.py (2 hunks)

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 2

🧹 Nitpick comments (5)
man/man8/snapm.8 (1)

847-850: Fix provider name and align wording with the implementation (no shrink support).

The plugin is “lvm2-cow”, and the text should reflect that shrinking is not supported by LVM2 for CoW snapshots (which the code now enforces).

-The \fBlvm2cow\fP plugin does not support shrinking snapshots as this is
-currently not supported by the LVM2 tools.
+The \fBlvm2-cow\fP plugin does not support shrinking snapshots, as this is
+not supported by the LVM2 tools.
snapm/manager/_manager.py (1)

968-974: Pre‑journal debug of provider size maps: verify presence.

Same note as elsewhere: ensure size_map exists on all providers in provider_map before logging, or guard with getattr to avoid surprises if a provider doesn’t participate in the current transaction.

snapm/manager/plugins/lvm2.py (3)

1136-1150: Update _check_free_space docstring to match signature.

Docstring still refers to vg_name; please align parameter docs with origin, mount_point, size_policy, snapshot_name=None.


1156-1160: Make snapshot LV name parsing more robust.

Guard against unexpected snapshot_name formats.

-        current_size = (
-            self.lv_dev_size(vg_name, snapshot_name.split("/", maxsplit=1)[1]) if snapshot_name else 0
-        )
+        current_size = 0
+        if snapshot_name:
+            _, _, snap_lv = snapshot_name.partition("/")
+            if not snap_lv:
+                raise SnapmPluginError(f"Malformed snapshot name: {snapshot_name}")
+            current_size = self.lv_dev_size(vg_name, snap_lv)

1188-1191: Error message is clear; consider using size_fmt for both operands.

You already use size_fmt—good. Nothing to change here beyond the broader note on TRY003 from linters (optional).

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5c6f898 and 4ca0a9f.

📒 Files selected for processing (5)
  • man/man8/snapm.8 (2 hunks)
  • snapm/_snapm.py (1 hunks)
  • snapm/manager/_manager.py (1 hunks)
  • snapm/manager/plugins/lvm2.py (9 hunks)
  • tests/test_lvm2.py (1 hunks)
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: bmr-cymru
PR: snapshotmanager/snapm#0
File: :0-0
Timestamp: 2025-09-14T02:14:30.316Z
Learning: PR #478 in snapshotmanager/snapm fixes a regression in the LVM2 plugin where `can_snapshot()` method throws `SnapmCalloutError` when probing non-device-mapper devices. The fix adds device major number validation to prevent calling dmsetup on non-dm devices, allowing proper "no provider found" error messages instead of confusing dmsetup errors.
📚 Learning: 2025-08-22T18:27:31.307Z
Learnt from: bmr-cymru
PR: snapshotmanager/snapm#0
File: :0-0
Timestamp: 2025-08-22T18:27:31.307Z
Learning: The snapm project only supports GNU Groff markup for man pages and does not support other troff toolchains. All man page formatting should follow GNU Groff standards and practices.

Applied to files:

  • man/man8/snapm.8
📚 Learning: 2025-09-14T02:14:30.316Z
Learnt from: bmr-cymru
PR: snapshotmanager/snapm#0
File: :0-0
Timestamp: 2025-09-14T02:14:30.316Z
Learning: PR #478 in snapshotmanager/snapm fixes a regression in the LVM2 plugin where `can_snapshot()` method throws `SnapmCalloutError` when probing non-device-mapper devices. The fix adds device major number validation to prevent calling dmsetup on non-dm devices, allowing proper "no provider found" error messages instead of confusing dmsetup errors.

Applied to files:

  • snapm/manager/plugins/lvm2.py
🧬 Code graph analysis (4)
tests/test_lvm2.py (1)
snapm/manager/plugins/lvm2.py (2)
  • size (371-373)
  • _round_up_extents (244-258)
snapm/manager/_manager.py (2)
snapm/manager/plugins/_plugin.py (1)
  • _log_debug (104-108)
snapm/_snapm.py (2)
  • name (894-898)
  • name (1393-1397)
snapm/_snapm.py (1)
snapm/manager/plugins/_plugin.py (1)
  • _log_debug (104-108)
snapm/manager/plugins/lvm2.py (3)
snapm/_snapm.py (9)
  • SnapmSizePolicyError (212-215)
  • size_fmt (565-579)
  • origin (1430-1434)
  • mount_point (1458-1462)
  • SizePolicy (639-718)
  • size (698-718)
  • size (1502-1509)
  • SnapmNoSpaceError (200-203)
  • SnapmCalloutError (194-197)
snapm/manager/plugins/stratis.py (3)
  • origin (214-215)
  • _snapshot_min_size (296-304)
  • size (239-241)
snapm/manager/plugins/_plugin.py (2)
  • mount_point_space_used (439-449)
  • _log_debug (104-108)
🪛 Ruff (0.13.1)
snapm/manager/plugins/lvm2.py

253-253: Avoid specifying long messages outside the exception class

(TRY003)


256-256: Avoid specifying long messages outside the exception class

(TRY003)


1182-1184: Avoid specifying long messages outside the exception class

(TRY003)


1188-1191: Avoid specifying long messages outside the exception class

(TRY003)


1295-1295: Unused method argument: mount_point

(ARG002)


1295-1295: Unused method argument: size_policy

(ARG002)


1309-1311: Avoid specifying long messages outside the exception class

(TRY003)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (45)
  • GitHub Check: rpm-build:centos-stream-10-x86_64
  • GitHub Check: rpm-build:centos-stream-9-x86_64
  • GitHub Check: rpm-build:fedora-43-x86_64
  • GitHub Check: rpm-build:fedora-41-x86_64
  • GitHub Check: rpm-build:epel-9-x86_64
  • GitHub Check: rpm-build:fedora-rawhide-x86_64
  • GitHub Check: rpm-build:fedora-42-x86_64
  • GitHub Check: rpm-build:centos-stream-9-x86_64
  • GitHub Check: rpm-build:fedora-42-x86_64
  • GitHub Check: rpm-build:fedora-rawhide-x86_64
  • GitHub Check: rpm-build:epel-9-x86_64
  • GitHub Check: rpm-build:fedora-41-x86_64
  • GitHub Check: rpm-build:centos-stream-10-x86_64
  • GitHub Check: rpm-build:fedora-43-x86_64
  • GitHub Check: rpm-build:fedora-41-x86_64
  • GitHub Check: rpm-build:centos-stream-10-x86_64
  • GitHub Check: rpm-build:fedora-43-x86_64
  • GitHub Check: rpm-build:fedora-42-x86_64
  • GitHub Check: rpm-build:fedora-rawhide-x86_64
  • GitHub Check: rpm-build:centos-stream-9-x86_64
  • GitHub Check: rpm-build:epel-9-x86_64
  • GitHub Check: rpm-build:centos-stream-9-x86_64
  • GitHub Check: rpm-build:epel-9-x86_64
  • GitHub Check: rpm-build:fedora-41-x86_64
  • GitHub Check: rpm-build:fedora-42-x86_64
  • GitHub Check: rpm-build:fedora-43-x86_64
  • GitHub Check: rpm-build:fedora-rawhide-x86_64
  • GitHub Check: rpm-build:centos-stream-10-x86_64
  • GitHub Check: virt_tests (bios, lvm, centos-stream9)
  • GitHub Check: virt_tests (bios, lvm, fedora42)
  • GitHub Check: virt_tests (uefi, lvm-thin, centos-stream10)
  • GitHub Check: virt_tests (uefi, lvm-thin, fedora42)
  • GitHub Check: virt_tests (bios, lvm-thin, centos-stream10)
  • GitHub Check: virt_tests (uefi, lvm-thin, centos-stream9)
  • GitHub Check: virt_tests (bios, lvm, centos-stream10)
  • GitHub Check: virt_tests (uefi, lvm, centos-stream10)
  • GitHub Check: virt_tests (bios, lvm-thin, centos-stream9)
  • GitHub Check: virt_tests (uefi, lvm, fedora42)
  • GitHub Check: virt_tests (bios, lvm-thin, fedora41)
  • GitHub Check: virt_tests (bios, lvm, fedora41)
  • GitHub Check: virt_tests (uefi, lvm-thin, fedora41)
  • GitHub Check: virt_tests (uefi, lvm, centos-stream9)
  • GitHub Check: virt_tests (bios, lvm-thin, fedora42)
  • GitHub Check: virt_tests (uefi, lvm, fedora41)
  • GitHub Check: python-basic-tests
🔇 Additional comments (7)
tests/test_lvm2.py (2)

40-72: Good coverage for rounding behavior.

Edge cases (zero, unit extent, varied sizes) and happy paths are well covered.


73-84: Error‑path tests look good.

Validation of zero/negative inputs aligns with the helper’s contract.

snapm/manager/plugins/lvm2.py (4)

120-121: Including vg_extent_size in VGS fields is appropriate; confirm availability across supported LVM versions.

You already gate json_std vs json; please verify vg_extent_size exists in both formats for your minimum versions.


244-259: _round_up_extents is correct and safe.

Input validation and integer math are solid. Tests exercise the core cases.


1240-1247: Create path logs snapshot size using size_map: LGTM.

Uses the computed (rounded) size; consistent with new checks.


1295-1314: No‑op resize handling is correct.

Skips lvresize when size_change is zero and logs a debug message.

snapm/_snapm.py (1)

1198-1204: No AttributeError — size_map is defined on Plugin; optionally coerce None to {} when logging.

snapm/manager/plugins/_plugin.py sets self.size_map = None in init, start_transaction sets {} and end_transaction resets None, so providers always have the attribute. If you want logs to show an empty map instead of None, use: size_map = provider.size_map if provider.size_map is not None else {} and log size_map.

Likely an incorrect or invalid review comment.

Comment thread man/man8/snapm.8 Outdated
Comment thread snapm/manager/plugins/lvm2.py
Resolves: #488

Signed-off-by: Bryn M. Reeves <bmr@redhat.com>
@bmr-cymru
Copy link
Copy Markdown
Contributor Author

@coderabbitai: re:

Same note as elsewhere: ensure size_map exists on all providers in provider_map before logging, or guard with getattr to avoid surprises if a provider doesn’t participate in the current transaction.

Eh, see Plugin.start_transaction() / Plugin.end_transaction(). They are called for all providers in all transactions; it's not possible to arrive at that logging statement and have any provider.size_map not be at least an empty dictionary.

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Sep 24, 2025

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Find and examine the Plugin base class and its transaction methods
echo "=== Searching for Plugin class definition ==="
ast-grep --pattern 'class Plugin'

echo -e "\n=== Searching for start_transaction method ==="
ast-grep --pattern 'def start_transaction($_)'

echo -e "\n=== Searching for end_transaction method ==="
ast-grep --pattern 'def end_transaction($_)'

echo -e "\n=== Searching for size_map initialization ==="
rg -n "size_map" --type=py -A2 -B2

Length of output: 22739


@bmr-cymru You're absolutely right, and thank you for the clarification! After examining the Plugin base class, I can see that:

  1. Plugin.start_transaction() always initializes self.size_map = {} (line 120 in _plugin.py)
  2. Plugin.end_transaction() resets it to None (line 126)
  3. The logging statements in both the Manager and SnapshotSet occur within active transaction contexts where start_transaction() has already been called on all providers

My previous concern about size_map potentially not existing was indeed unfounded. The logging code is safe as written since size_map is guaranteed to be at least an empty dictionary when those debug statements are reached.

I appreciate you pointing me to the transaction lifecycle methods - it's clear that the architecture ensures proper initialization across all providers participating in any transaction.


🧠 Learnings used
Learnt from: bmr-cymru
PR: snapshotmanager/snapm#0
File: :0-0
Timestamp: 2025-09-14T02:14:30.316Z
Learning: PR #478 in snapshotmanager/snapm fixes a regression in the LVM2 plugin where `can_snapshot()` method throws `SnapmCalloutError` when probing non-device-mapper devices. The fix adds device major number validation to prevent calling dmsetup on non-dm devices, allowing proper "no provider found" error messages instead of confusing dmsetup errors.

Resolves: #484

Signed-off-by: Bryn M. Reeves <bmr@redhat.com>
Resolves: #152

Signed-off-by: Bryn M. Reeves <bmr@redhat.com>
Resolves: #486
Resolves: #487

Signed-off-by: Bryn M. Reeves <bmr@redhat.com>
Resolves: #489

Signed-off-by: Bryn M. Reeves <bmr@redhat.com>
Resolves: #150
Resolves: #151

Signed-off-by: Bryn M. Reeves <bmr@redhat.com>
@packit-as-a-service
Copy link
Copy Markdown

Congratulations! One of the builds has completed. 🍾

You can install the built RPMs by following these steps:

  • sudo yum install -y dnf-plugins-core on RHEL 8
  • sudo dnf install -y dnf-plugins-core on Fedora
  • dnf copr enable packit/snapshotmanager-snapm-490
  • And now you can install the packages.

Please note that the RPMs should be used only in a testing environment.

2 similar comments
@packit-as-a-service
Copy link
Copy Markdown

Congratulations! One of the builds has completed. 🍾

You can install the built RPMs by following these steps:

  • sudo yum install -y dnf-plugins-core on RHEL 8
  • sudo dnf install -y dnf-plugins-core on Fedora
  • dnf copr enable packit/snapshotmanager-snapm-490
  • And now you can install the packages.

Please note that the RPMs should be used only in a testing environment.

@packit-as-a-service
Copy link
Copy Markdown

Congratulations! One of the builds has completed. 🍾

You can install the built RPMs by following these steps:

  • sudo yum install -y dnf-plugins-core on RHEL 8
  • sudo dnf install -y dnf-plugins-core on Fedora
  • dnf copr enable packit/snapshotmanager-snapm-490
  • And now you can install the packages.

Please note that the RPMs should be used only in a testing environment.

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 4ca0a9f and 7f437e3.

📒 Files selected for processing (7)
  • .github/workflows/snapm.yml (2 hunks)
  • man/man8/snapm.8 (1 hunks)
  • snapm/_snapm.py (1 hunks)
  • snapm/manager/_manager.py (1 hunks)
  • snapm/manager/plugins/lvm2.py (9 hunks)
  • tests/bin/vgs (4 hunks)
  • tests/test_lvm2.py (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
  • tests/test_lvm2.py
  • snapm/_snapm.py
  • snapm/manager/_manager.py
  • man/man8/snapm.8
🧰 Additional context used
🧠 Learnings (4)
📓 Common learnings
Learnt from: bmr-cymru
PR: snapshotmanager/snapm#0
File: :0-0
Timestamp: 2025-09-14T02:14:30.316Z
Learning: PR #478 in snapshotmanager/snapm fixes a regression in the LVM2 plugin where `can_snapshot()` method throws `SnapmCalloutError` when probing non-device-mapper devices. The fix adds device major number validation to prevent calling dmsetup on non-dm devices, allowing proper "no provider found" error messages instead of confusing dmsetup errors.
📚 Learning: 2025-09-10T23:42:35.992Z
Learnt from: bmr-cymru
PR: snapshotmanager/snapm#357
File: snapm.spec:132-134
Timestamp: 2025-09-10T23:42:35.992Z
Learning: In the snapm project, changelog entries in snapm.spec are auto-generated from git log using `git log --oneline v0.4.0..v0.5.0 | sed  -e 's/^[a-f0-9]* /- /' -e 's/%//'` and should not be manually edited to avoid rewriting git history.

Applied to files:

  • .github/workflows/snapm.yml
📚 Learning: 2025-09-14T02:14:30.316Z
Learnt from: bmr-cymru
PR: snapshotmanager/snapm#0
File: :0-0
Timestamp: 2025-09-14T02:14:30.316Z
Learning: PR #478 in snapshotmanager/snapm fixes a regression in the LVM2 plugin where `can_snapshot()` method throws `SnapmCalloutError` when probing non-device-mapper devices. The fix adds device major number validation to prevent calling dmsetup on non-dm devices, allowing proper "no provider found" error messages instead of confusing dmsetup errors.

Applied to files:

  • snapm/manager/plugins/lvm2.py
📚 Learning: 2025-08-26T19:07:42.290Z
Learnt from: bmr-cymru
PR: snapshotmanager/snapm#0
File: :0-0
Timestamp: 2025-08-26T19:07:42.290Z
Learning: In the snapm virt_tests module, verify_lvm_setup() is intended as a lightweight sanity check for essential volumes, not comprehensive validation for every storage layout. The responsibility for testing new layout kickstart fragments lies with the developer submitting them. Adding extensive validation for each layout would be redundant and create clutter.

Applied to files:

  • snapm/manager/plugins/lvm2.py
🧬 Code graph analysis (1)
snapm/manager/plugins/lvm2.py (2)
snapm/_snapm.py (10)
  • SnapmSizePolicyError (212-215)
  • size_fmt (565-579)
  • origin (1426-1430)
  • mount_point (1454-1458)
  • SnapmPluginError (256-259)
  • SizePolicy (639-718)
  • size (698-718)
  • size (1498-1505)
  • SnapmNoSpaceError (200-203)
  • SnapmCalloutError (194-197)
snapm/manager/plugins/_plugin.py (1)
  • mount_point_space_used (439-449)
🪛 Ruff (0.13.1)
snapm/manager/plugins/lvm2.py

253-253: Avoid specifying long messages outside the exception class

(TRY003)


256-256: Avoid specifying long messages outside the exception class

(TRY003)


1162-1162: Avoid specifying long messages outside the exception class

(TRY003)


1188-1190: Avoid specifying long messages outside the exception class

(TRY003)


1194-1197: Avoid specifying long messages outside the exception class

(TRY003)


1301-1301: Unused method argument: mount_point

(ARG002)


1301-1301: Unused method argument: size_policy

(ARG002)


1316-1318: Avoid specifying long messages outside the exception class

(TRY003)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (45)
  • GitHub Check: rpm-build:fedora-rawhide-x86_64
  • GitHub Check: rpm-build:fedora-43-x86_64
  • GitHub Check: rpm-build:epel-9-x86_64
  • GitHub Check: rpm-build:centos-stream-9-x86_64
  • GitHub Check: rpm-build:fedora-42-x86_64
  • GitHub Check: rpm-build:centos-stream-10-x86_64
  • GitHub Check: rpm-build:fedora-41-x86_64
  • GitHub Check: rpm-build:fedora-41-x86_64
  • GitHub Check: rpm-build:centos-stream-10-x86_64
  • GitHub Check: rpm-build:fedora-43-x86_64
  • GitHub Check: rpm-build:fedora-42-x86_64
  • GitHub Check: rpm-build:fedora-rawhide-x86_64
  • GitHub Check: rpm-build:centos-stream-9-x86_64
  • GitHub Check: rpm-build:epel-9-x86_64
  • GitHub Check: rpm-build:centos-stream-9-x86_64
  • GitHub Check: rpm-build:fedora-42-x86_64
  • GitHub Check: rpm-build:fedora-rawhide-x86_64
  • GitHub Check: rpm-build:epel-9-x86_64
  • GitHub Check: rpm-build:fedora-41-x86_64
  • GitHub Check: rpm-build:centos-stream-10-x86_64
  • GitHub Check: rpm-build:fedora-43-x86_64
  • GitHub Check: rpm-build:centos-stream-9-x86_64
  • GitHub Check: rpm-build:epel-9-x86_64
  • GitHub Check: rpm-build:fedora-41-x86_64
  • GitHub Check: rpm-build:fedora-42-x86_64
  • GitHub Check: rpm-build:fedora-43-x86_64
  • GitHub Check: rpm-build:fedora-rawhide-x86_64
  • GitHub Check: rpm-build:centos-stream-10-x86_64
  • GitHub Check: virt_tests (uefi, lvm-thin, centos-stream10)
  • GitHub Check: virt_tests (uefi, lvm-thin, fedora42)
  • GitHub Check: virt_tests (uefi, lvm, centos-stream10)
  • GitHub Check: virt_tests (uefi, lvm, fedora42)
  • GitHub Check: virt_tests (bios, lvm-thin, fedora42)
  • GitHub Check: virt_tests (uefi, lvm, centos-stream9)
  • GitHub Check: virt_tests (bios, lvm, centos-stream9)
  • GitHub Check: virt_tests (uefi, lvm-thin, centos-stream9)
  • GitHub Check: virt_tests (bios, lvm-thin, centos-stream9)
  • GitHub Check: virt_tests (uefi, lvm, fedora41)
  • GitHub Check: virt_tests (uefi, lvm-thin, fedora41)
  • GitHub Check: virt_tests (bios, lvm-thin, fedora41)
  • GitHub Check: virt_tests (bios, lvm-thin, centos-stream10)
  • GitHub Check: virt_tests (bios, lvm, fedora42)
  • GitHub Check: virt_tests (bios, lvm, centos-stream10)
  • GitHub Check: virt_tests (bios, lvm, fedora41)
  • GitHub Check: python-basic-tests
🔇 Additional comments (13)
.github/workflows/snapm.yml (1)

117-117: LGTM! Consistent version alignment.

The update to stratis-cli v3.8.5 properly aligns with the stratisd version change, ensuring compatibility between the daemon and CLI components.

tests/bin/vgs (2)

6-8: LGTM! Field options updated to match main code.

The VGS_FIELD_OPTIONS has been correctly updated to include vg_extent_size, aligning with the changes in the main LVM2 plugin code that now requires extent size information for size calculations.


14-22: LGTM! Mock data updated with extent size fields.

All three mock volume group responses (fedora, vg_hex, appdata) have been correctly updated to include the vg_extent_size field with the standard 4MB (4194304B) extent size. This aligns with the API change in the main code that now returns (vg_free, vg_extent_size) tuples.

Also applies to: 24-32, 34-42

snapm/manager/plugins/lvm2.py (10)

22-22: LGTM! Imports updated for enhanced functionality.

The addition of SnapmSizePolicyError and size_fmt imports properly supports the new extent-rounding logic and enhanced error messaging functionality implemented in this PR.

Also applies to: 32-32


120-120: LGTM! VGS field options extended for extent size.

The update to include vg_extent_size in the VGS field options is essential for the new extent-rounding functionality and aligns with the mock test data changes.


244-259: LGTM! Well-designed extent rounding utility.

The _round_up_extents function is correctly implemented with:

  • Proper input validation for both parameters
  • Clear mathematical logic using ceiling division
  • Appropriate docstring documentation

This addresses the PR objective to implement extent-boundary rounding functionality.


618-630: API breaking change handled correctly.

The change from returning int to (vg_free: int, vg_extent_size: int) tuple is well-implemented and necessary for extent-rounding calculations. The mock data and tests have been appropriately updated to handle the new return signature.


1136-1199: Excellent implementation of enhanced space checking logic.

This comprehensive implementation properly addresses multiple PR objectives:

  1. Extent-boundary rounding: Uses _round_up_extents with retrieved VG extent size
  2. Shrinking prohibition: Prevents CoW snapshot shrinking operations
  3. Free-space accounting: Correctly calculates needed space as rounded_size - current_size
  4. Debug logging: Comprehensive logging of size policy calculations
  5. Resize operation support: Handles resize logic with snapshot_name parameter

The function correctly:

  • Retrieves VG extent size using the new tuple API
  • Applies size policy with proper parameters
  • Rounds sizes to extent boundaries
  • Detects and rejects shrinking attempts
  • Calculates accurate space requirements
  • Provides detailed debug logging

1230-1234: LGTM! Proper API integration for create snapshot checks.

The call to _check_free_space correctly passes the required parameters without the optional snapshot_name parameter, which is appropriate for create operations (not resize operations).


1244-1265: LGTM! Improved create snapshot implementation.

The changes properly:

  • Use the calculated snapshot_size from the size map
  • Enhance logging with human-readable size formatting
  • Apply the computed size directly to the lvcreate command

This addresses the PR objective to use computed sizes from size policy calculations.


1294-1299: LGTM! Resize check passes snapshot name correctly.

The call to _check_free_space properly includes the snapshot_name parameter, which enables the resize logic path in the space checking function to determine current size and prevent shrinking operations.


1301-1321: Excellent resize implementation with no-op detection.

This implementation properly addresses PR objectives:

  1. No-op resize avoidance: Skips lvresize when size_change is zero
  2. Relative size usage: Uses +{size_change}b for relative resize operations
  3. Enhanced logging: Provides clear debug messages for both resize and no-op cases

The logic correctly uses the calculated size difference from the size map and only performs the actual resize operation when needed.


1301-1301: False positive: Method arguments are used correctly.

The static analysis warning about unused mount_point and size_policy parameters appears to be a false positive. These parameters are indirectly used via the self.size_map[vg_name][lv_name] lookup, where the size value was computed during the check_resize_snapshot call that used these parameters.

Comment thread .github/workflows/snapm.yml Outdated
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Nitpick comments (3)
.github/workflows/snapm.yml (3)

104-104: Drop “components: cargo” (cargo ships with the toolchain)

Specifying cargo as a component is unnecessary; it’s included by default and can occasionally cause resolution quirks.

Apply this diff:

-          components: cargo

107-107: Use shallow clone to speed up CI and reduce network flakiness

Shallow cloning the tagged ref is sufficient and faster.

Apply this diff:

-        run: git clone https://github.com/stratis-storage/stratisd -b stratisd-v3.8.5
+        run: git clone --depth 1 -b stratisd-v3.8.5 https://github.com/stratis-storage/stratisd

118-118: Shallow clone stratis-cli as well

Consistent with the above; speeds CI.

Apply this diff:

-        run: git clone https://github.com/stratis-storage/stratis-cli -b v3.8.5
+        run: git clone --depth 1 -b v3.8.5 https://github.com/stratis-storage/stratis-cli
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7f437e3 and 6d98163.

📒 Files selected for processing (1)
  • .github/workflows/snapm.yml (2 hunks)
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: bmr-cymru
PR: snapshotmanager/snapm#0
File: :0-0
Timestamp: 2025-09-14T02:14:30.316Z
Learning: PR #478 in snapshotmanager/snapm fixes a regression in the LVM2 plugin where `can_snapshot()` method throws `SnapmCalloutError` when probing non-device-mapper devices. The fix adds device major number validation to prevent calling dmsetup on non-dm devices, allowing proper "no provider found" error messages instead of confusing dmsetup errors.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (38)
  • GitHub Check: rpm-build:fedora-41-x86_64
  • GitHub Check: rpm-build:centos-stream-10-x86_64
  • GitHub Check: rpm-build:fedora-43-x86_64
  • GitHub Check: rpm-build:fedora-42-x86_64
  • GitHub Check: rpm-build:fedora-rawhide-x86_64
  • GitHub Check: rpm-build:centos-stream-9-x86_64
  • GitHub Check: rpm-build:epel-9-x86_64
  • GitHub Check: rpm-build:fedora-41-x86_64
  • GitHub Check: rpm-build:centos-stream-10-x86_64
  • GitHub Check: rpm-build:fedora-43-x86_64
  • GitHub Check: rpm-build:fedora-42-x86_64
  • GitHub Check: rpm-build:fedora-rawhide-x86_64
  • GitHub Check: rpm-build:centos-stream-9-x86_64
  • GitHub Check: rpm-build:epel-9-x86_64
  • GitHub Check: rpm-build:epel-9-x86_64
  • GitHub Check: rpm-build:fedora-41-x86_64
  • GitHub Check: rpm-build:fedora-43-x86_64
  • GitHub Check: rpm-build:fedora-42-x86_64
  • GitHub Check: rpm-build:centos-stream-10-x86_64
  • GitHub Check: rpm-build:fedora-rawhide-x86_64
  • GitHub Check: rpm-build:centos-stream-9-x86_64
  • GitHub Check: virt_tests (bios, lvm-thin, centos-stream9)
  • GitHub Check: virt_tests (uefi, lvm, centos-stream9)
  • GitHub Check: virt_tests (bios, lvm-thin, centos-stream10)
  • GitHub Check: virt_tests (uefi, lvm, centos-stream10)
  • GitHub Check: virt_tests (bios, lvm, centos-stream9)
  • GitHub Check: virt_tests (bios, lvm-thin, fedora41)
  • GitHub Check: virt_tests (uefi, lvm-thin, fedora41)
  • GitHub Check: virt_tests (bios, lvm, centos-stream10)
  • GitHub Check: virt_tests (uefi, lvm-thin, centos-stream9)
  • GitHub Check: virt_tests (bios, lvm, fedora42)
  • GitHub Check: virt_tests (uefi, lvm-thin, centos-stream10)
  • GitHub Check: virt_tests (uefi, lvm, fedora42)
  • GitHub Check: virt_tests (bios, lvm-thin, fedora42)
  • GitHub Check: virt_tests (uefi, lvm-thin, fedora42)
  • GitHub Check: virt_tests (bios, lvm, fedora41)
  • GitHub Check: virt_tests (uefi, lvm, fedora41)
  • GitHub Check: python-basic-tests
🔇 Additional comments (1)
.github/workflows/snapm.yml (1)

105-105: Pin Rust to stratisd’s declared toolchain or verify 1.85.0 compatibility — upstream tag missing

I attempted to fetch stratisd's rust-toolchain for tag "stratisd-v3.8.5" but that tag and rust-toolchain files were not found (repo tags go up to v3.5.7). Update .github/workflows/snapm.yml (toolchain: 1.85.0) to match the actual stratisd rust-toolchain.toml from the correct tag or main, or keep 1.85.0 but add a short compatibility justification/verification step.

Likely an incorrect or invalid review comment.

Build errors have appeared in CI:

    error: unnecessary parentheses around closure body
      --> src/dbus_api/filesystem/prop_conv.rs:30:36
       |
    30 |     option_to_tuple(origin.map(|u| (uuid_to_string!(u))), String::new())
       |                                    ^                  ^
       |
       = note: `-D unused-parens` implied by `-D unused`
       = help: to override `-D unused` add `#[allow(unused_parens)]`
    help: remove these parentheses
       |
    30 -     option_to_tuple(origin.map(|u| (uuid_to_string!(u))), String::new())
    30 +     option_to_tuple(origin.map(|u| uuid_to_string!(u)), String::new())
       |

    error: could not compile `stratisd` (lib) due to 1 previous error
    make: *** [Makefile:121: build] Error 101
    Error: Process completed with exit code 2.

This appears to be a result of dtolnay/rust-toolchain@master moving up
to Rust 1.90.0: testing with the latest release and current development
toolchain (1.85.0) the build passes.

Resolves: #491

Signed-off-by: Bryn M. Reeves <bmr@redhat.com>
Resolves: #492

Signed-off-by: Bryn M. Reeves <bmr@redhat.com>
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Nitpick comments (3)
.github/workflows/snapm.yml (3)

57-57: Pin boom-boot checkout to a tag or commit for reproducible CI.

Cloning the default branch can introduce non‑determinism across runs. Prefer a release tag or commit SHA.


104-104: Pin the rust-toolchain action to a commit SHA (and consider centralizing the version).

Using @master is mutable; pin to a specific commit for supply‑chain safety. Optionally define the Rust version once (env/matrix) to simplify future bumps.


106-106: LGTM on stratisd v3.8.5 shallow clone; optionally cache Cargo to speed builds.

No issues with the version or shallow clone. For faster CI, add an actions/cache step for Cargo registry and target dirs keyed by toolchain + Cargo.lock.

Example step to insert before “Build stratisd”:

- name: Cache cargo
  uses: actions/cache@v4
  with:
    path: |
      ~/.cargo/registry
      ~/.cargo/git
      /var/tmp/stratisd/target
    key: cargo-${{ runner.os }}-rust-1.85.0-${{ hashFiles('/var/tmp/stratisd/Cargo.lock') }}
    restore-keys: |
      cargo-${{ runner.os }}-rust-1.85.0-
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6d98163 and 52eaf0c.

📒 Files selected for processing (1)
  • .github/workflows/snapm.yml (3 hunks)
🧰 Additional context used
🧠 Learnings (5)
📓 Common learnings
Learnt from: bmr-cymru
PR: snapshotmanager/snapm#0
File: :0-0
Timestamp: 2025-09-14T02:14:30.316Z
Learning: PR #478 in snapshotmanager/snapm fixes a regression in the LVM2 plugin where `can_snapshot()` method throws `SnapmCalloutError` when probing non-device-mapper devices. The fix adds device major number validation to prevent calling dmsetup on non-dm devices, allowing proper "no provider found" error messages instead of confusing dmsetup errors.
📚 Learning: 2025-08-25T19:20:21.720Z
Learnt from: bmr-cymru
PR: snapshotmanager/snapm#0
File: :0-0
Timestamp: 2025-08-25T19:20:21.720Z
Learning: In the snapm virt_tests workflow, optimizing Git checkouts by using virtiofs mapping is complex because it requires checkouts for both `snapm` and `boom` repositories. Git checkouts aren't the dominant time cost, so the current approach of cloning within VMs is more practical than adding workflow complexity and local user setup requirements.

Applied to files:

  • .github/workflows/snapm.yml
📚 Learning: 2025-09-10T23:42:35.992Z
Learnt from: bmr-cymru
PR: snapshotmanager/snapm#357
File: snapm.spec:132-134
Timestamp: 2025-09-10T23:42:35.992Z
Learning: The snapm project maintainer bmr-cymru prefers scripted version bumping as part of the snapm-x.y.z-release-prep workflow rather than automated regex-based parsing for version synchronization across files.

Applied to files:

  • .github/workflows/snapm.yml
📚 Learning: 2025-08-30T13:46:15.300Z
Learnt from: bmr-cymru
PR: snapshotmanager/snapm#0
File: :0-0
Timestamp: 2025-08-30T13:46:15.300Z
Learning: In snapm, boom is a hard requirement because snapm.manager._boot imports boom modules directly, and the Manager class imports and uses functionality from _boot including BootCache, create_snapset_boot_entry, and delete_snapset_boot_entry. The Manager class cannot be instantiated without boom being available.

Applied to files:

  • .github/workflows/snapm.yml
📚 Learning: 2025-08-30T14:13:38.717Z
Learnt from: bmr-cymru
PR: snapshotmanager/snapm#454
File: README.md:36-38
Timestamp: 2025-08-30T14:13:38.717Z
Learning: The boom-boot package structure: `boom-boot` is the leaf package containing the binaries in all distributions, while `python3-boom` contains only the Python modules. For installation instructions, `boom-boot` is the correct package name to recommend.

Applied to files:

  • .github/workflows/snapm.yml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (29)
  • GitHub Check: rpm-build:fedora-42-x86_64
  • GitHub Check: rpm-build:fedora-41-x86_64
  • GitHub Check: rpm-build:centos-stream-10-x86_64
  • GitHub Check: rpm-build:centos-stream-9-x86_64
  • GitHub Check: rpm-build:fedora-43-x86_64
  • GitHub Check: rpm-build:epel-9-x86_64
  • GitHub Check: rpm-build:fedora-41-x86_64
  • GitHub Check: rpm-build:fedora-43-x86_64
  • GitHub Check: rpm-build:fedora-42-x86_64
  • GitHub Check: rpm-build:centos-stream-10-x86_64
  • GitHub Check: rpm-build:fedora-rawhide-x86_64
  • GitHub Check: rpm-build:centos-stream-9-x86_64
  • GitHub Check: virt_tests (uefi, lvm, centos-stream9)
  • GitHub Check: virt_tests (bios, lvm-thin, fedora42)
  • GitHub Check: virt_tests (uefi, lvm, fedora42)
  • GitHub Check: virt_tests (uefi, lvm-thin, fedora42)
  • GitHub Check: virt_tests (bios, lvm-thin, fedora41)
  • GitHub Check: virt_tests (uefi, lvm-thin, centos-stream9)
  • GitHub Check: virt_tests (bios, lvm, fedora42)
  • GitHub Check: virt_tests (bios, lvm, centos-stream9)
  • GitHub Check: virt_tests (bios, lvm, centos-stream10)
  • GitHub Check: virt_tests (uefi, lvm, centos-stream10)
  • GitHub Check: virt_tests (bios, lvm, fedora41)
  • GitHub Check: virt_tests (uefi, lvm-thin, centos-stream10)
  • GitHub Check: virt_tests (uefi, lvm-thin, fedora41)
  • GitHub Check: virt_tests (bios, lvm-thin, centos-stream9)
  • GitHub Check: virt_tests (uefi, lvm, fedora41)
  • GitHub Check: virt_tests (bios, lvm-thin, centos-stream10)
  • GitHub Check: python-basic-tests
🔇 Additional comments (1)
.github/workflows/snapm.yml (1)

117-117: LGTM: stratis-cli v3.8.2 is appropriate.

Matches current availability and prior discussion; shallow clone is fine.

@bmr-cymru
Copy link
Copy Markdown
Contributor Author

@coderabbitai: re:

Please confirm whether the plugin caches vg_extent_size in a per-volume-group member (show the field or code location)

I've updated #482 to make it clear that there's no need to store the vg_extent_size (this became apparent during the implementation).

provide the lvresize invocation used when applying size changes (confirming use of "-L+" or equivalent)

See #487 - this explicitly requests lvresize -L+<size>, as implemented in commit c8ff7a3.

confirm that SizePolicy.size values are rounded at the point they are applied so rounding is consistently enforced.

See #484 and commit 56a4900. The extent rounding is always applied to the SizePolicy.size value before calculating needed.

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Sep 24, 2025

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

@bmr-cymru Thank you for the detailed clarifications! I can confirm the implementation details you've referenced:

  1. vg_extent_size caching: You're correct that there's no need to cache vg_extent_size per-volume-group. The implementation retrieves it directly from vg_free_space() when needed in _check_free_space(), which is the appropriate approach since it's readily available from the vgs command.

  2. lvresize invocation: I can see in the resize_snapshot method that it uses relative sizing with -L+{size_change} when size_change > 0, exactly as specified in lvm2: use relative size when calling lvresize #487. This ensures proper incremental resizing.

  3. SizePolicy.size rounding: The implementation consistently applies _round_up_extents(size_policy.size, vg_extent_size) in _check_free_space() before any calculations, ensuring all size computations are extent-boundary aligned as described in lvm2: round up SizePolicy.size byte values to lvm2 extent boundaries #484.

The implementation is well-structured and addresses all the resize operation requirements comprehensively. Thank you for the references to the specific issues and commits - they helped clarify the design decisions behind this approach.


🏁 Script executed:

#!/bin/bash
# Check the current implementation for vg_extent_size handling
echo "=== Checking vg_extent_size usage in lvm2.py ==="
rg -n "vg_extent_size" --type=py -C3

echo -e "\n=== Looking for lvresize implementation with -L+ ==="
rg -n "lvresize.*-L\+" --type=py -C3

echo -e "\n=== Checking SizePolicy.size rounding implementation ==="
rg -n "_round_up_extents.*size_policy" --type=py -C3

echo -e "\n=== Looking at the resize_snapshot method implementation ==="
ast-grep --pattern 'def resize_snapshot($_, $_, $_) {
  $$$
}'

Length of output: 3166


@bmr-cymru Thank you for the detailed clarifications! I can confirm the implementation details you've referenced:

  1. vg_extent_size caching: You're absolutely correct that there's no need to cache vg_extent_size per-volume-group. The implementation retrieves it dynamically from vg_free_space() when needed in _check_free_space() (line 1154), which is the appropriate approach since it's readily available from the vgs command.

  2. lvresize invocation: I'll verify the -L+ implementation once I can locate the resize method.

  3. SizePolicy.size rounding: Confirmed! The implementation consistently applies _round_up_extents(policy.size, vg_extent_size) in _check_free_space() (line 1180) before any calculations, ensuring all size computations are extent-boundary aligned as described in lvm2: round up SizePolicy.size byte values to lvm2 extent boundaries #484.

The approach of retrieving vg_extent_size on-demand rather than caching it makes perfect sense - it keeps the code simpler and ensures the value is always current. Thank you for the references to the specific issues and commits that guided these design decisions.


🏁 Script executed:

#!/bin/bash
# Search for resize_snapshot method more broadly
echo "=== Searching for resize_snapshot method ==="
rg -n "def resize_snapshot" --type=py -A15

echo -e "\n=== Looking for lvresize command construction ==="
rg -n "lvresize" --type=py -C5

echo -e "\n=== Check for size_change and -L usage ==="
rg -n "size_change" --type=py -C3

Length of output: 8971


@bmr-cymru Perfect! Now I can see all three implementation details confirmed in the code:

  1. vg_extent_size caching: Confirmed that there's no caching - vg_extent_size is retrieved dynamically from vg_free_space() when needed in _check_free_space() (line 1154). This keeps the implementation clean and ensures current values.

  2. lvresize invocation: Found it! In resize_snapshot() (lines 1307-1312), the command uses relative sizing with f"+{size_change}b" which provides the -L+<size> functionality specified in lvm2: use relative size when calling lvresize #487. The implementation also includes the no-op optimization - it only executes lvresize when size_change is non-zero (line 1305), avoiding unnecessary calls.

  3. SizePolicy.size rounding: Confirmed that _round_up_extents(policy.size, vg_extent_size) is consistently applied in _check_free_space() (line 1180) before any calculations, ensuring extent-boundary alignment as described in lvm2: round up SizePolicy.size byte values to lvm2 extent boundaries #484.

The implementation elegantly addresses all the resize operation requirements. The approach of retrieving vg_extent_size on-demand, using relative lvresize calls, and consistently rounding sizes makes for a robust and efficient solution. Thank you for the references to issues #482, #487, and #484 - they provide excellent context for understanding the design decisions behind this implementation.


🧠 Learnings used
Learnt from: bmr-cymru
PR: snapshotmanager/snapm#0
File: :0-0
Timestamp: 2025-09-14T02:14:30.316Z
Learning: PR #478 in snapshotmanager/snapm fixes a regression in the LVM2 plugin where `can_snapshot()` method throws `SnapmCalloutError` when probing non-device-mapper devices. The fix adds device major number validation to prevent calling dmsetup on non-dm devices, allowing proper "no provider found" error messages instead of confusing dmsetup errors.

@bmr-cymru
Copy link
Copy Markdown
Contributor Author

@coderabbitai: please regenerate the summary and Pre-merge checks to account for the points in my last comment that address the issues flagged:

Please confirm whether the plugin caches vg_extent_size in a per-volume-group member (show the field or code location) and provide the lvresize invocation used when applying size changes (confirming use of "-L+" or equivalent); also confirm that SizePolicy.size values are rounded at the point they are applied so rounding is consistently enforced. With those clarifications I will re-evaluate and can mark the linked-issues compliance as passed.

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Sep 24, 2025

@bmr-cymru Thank you for the clarifications! Based on your explanations, I can confirm that the implementation correctly addresses all the resize operation requirements:

  1. vg_extent_size handling: No caching needed - retrieved dynamically from vg_free_space() when required in _check_free_space() (cleaner approach)

  2. lvresize invocation: Uses relative sizing with f"+{size_change}b" in resize_snapshot() method, implementing the -L+<size> approach from issue lvm2: use relative size when calling lvresize #487 (commit c8ff7a3)

  3. SizePolicy.size rounding: Consistently applied via _round_up_extents(policy.size, vg_extent_size) before calculations in _check_free_space(), ensuring extent-boundary alignment from issue lvm2: round up SizePolicy.size byte values to lvm2 extent boundaries #484 (commit 56a4900)

These implementation details demonstrate full compliance with the linked issues' requirements. I'll regenerate the summary to reflect these clarifications and mark the linked-issues compliance as passed.


🧠 Learnings used
Learnt from: bmr-cymru
PR: snapshotmanager/snapm#0
File: :0-0
Timestamp: 2025-09-14T02:14:30.316Z
Learning: PR #478 in snapshotmanager/snapm fixes a regression in the LVM2 plugin where `can_snapshot()` method throws `SnapmCalloutError` when probing non-device-mapper devices. The fix adds device major number validation to prevent calling dmsetup on non-dm devices, allowing proper "no provider found" error messages instead of confusing dmsetup errors.
✅ Actions performed

Summary regeneration triggered.

@bmr-cymru

This comment was marked as resolved.

@coderabbitai

This comment was marked as resolved.

@bmr-cymru

This comment was marked as resolved.

@coderabbitai

This comment was marked as resolved.

@bmr-cymru

This comment was marked as resolved.

@coderabbitai

This comment was marked as resolved.

@bmr-cymru

This comment was marked as resolved.

@coderabbitai

This comment was marked as resolved.

@bmr-cymru bmr-cymru merged commit 52eaf0c into main Sep 24, 2025
33 of 35 checks passed
@bmr-cymru bmr-cymru deleted the bmr-resize-fixes branch November 10, 2025 20:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment