Actions
Bug #72957
openmgr/volumes: clone gets stuck in in-progress state
Status:
Pending Backport
Priority:
High
Assignee:
Category:
Correctness/Safety
Target version:
% Done:
0%
Source:
other
Backport:
tentacle
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(FS):
Labels (FS):
Pull request ID:
Tags (freeform):
backport_processed
Merge Commit:
Fixed In:
v20.3.0-5493-g71cab4cbaa
Released In:
Upkeep Timestamp:
2026-02-23T10:26:25+00:00
Description
If a subvolume's UUID dir is somehow lost/deleted by the user, just after running clone command but before cloninng actually begins, the clone gets stuck in in-progress state forever. All the subsequent calls to clone cancel failed to cancel the clone and all the calls to commands subvolume rm and subvolume snapshot rm fail to delete the subvolume as well as its snapshot even if --force is passed.
In such a state a clone's state should transition to "failed".
Updated by Rishabh Dave 6 months ago
- Subject changed from volumes: clone gets stuck in in-progress state to mgr/volumes: clone gets stuck in in-progress state
Updated by Rishabh Dave 6 months ago
- Status changed from New to Fix Under Review
Updated by Venky Shankar 20 days ago
- Category set to Correctness/Safety
- Status changed from Fix Under Review to Pending Backport
- Target version set to v21.0.0
- Source set to other
- Backport set to tentacle
Updated by Upkeep Bot 20 days ago
- Merge Commit set to 71cab4cbaabe6db1608deecb77b9b23c0005c276
- Fixed In set to v20.3.0-5493-g71cab4cbaa
- Upkeep Timestamp set to 2026-02-23T10:26:25+00:00
Updated by Upkeep Bot 20 days ago
- Copied to Backport #75094: tentacle: mgr/volumes: clone gets stuck in in-progress state added
Actions