Feature #44277
closedpybind/mgr/volumes: add command to return metadata regarding a subvolume
0%
Description
In Ceph CSI, there are cases where an existing subvolume needs to be inspected for a match to an incoming request. There are also possible future cases where we may need to list all CSI subvolumes and return its metadata to form the CSI context. A couple of examples are given below,
- An interrupted CreateVolume call in CSI can result in needing to inspect the already created subvolume to see if its size matchs the request
- An interrupted Createvolume call in CSI can result in needing to determine the already created subvolumes data pool extended attribute, to address topology response on a subsequent request for the same
Filing this issue to request a "subvolume info" extension to the CLI, possibly along the lines below,
ceph fs subvolume info <vol_name> <subvol_name> [--group_name <subvol_group_name> <--format [json|???]>]
The returned metadata needs to contain,
- Size (or quota set)
- Data pool (if set, or default etc.)
- CreatedAt timestamp
- Any other attributes, to be future safe
Also, a similar request info request is required for snapshots, to fetch information along the same lines as above. Hence, consider this request to add the info extension to "ceph fs subvolume snapshot" series of commands as well.
Further, would also like to understand how far back, in terms of Ceph versions, this can be backported once addressed, to determine both upstream and downstream version support for the same.
Updated by Patrick Donnelly about 4 years ago
- Subject changed from mgr/volumes: Require an extension to the cephfs subvolume commands, that can return metadata regarding a subvolume to pybind/mgr/volumes: add command to return metadata regarding a subvolume
- Priority changed from Normal to High
- Target version set to v16.0.0
- Backport set to octopus,nautilus
Updated by Kotresh Hiremath Ravishankar about 4 years ago
- Assignee set to Kotresh Hiremath Ravishankar
Updated by Kotresh Hiremath Ravishankar about 4 years ago
Hi Shyam,
I have discussed this tracker with Venky and require clarification. The requirement to check the size and data pool is to know whether the subvolume creation is successful and ready to use? If that's the only case, the getpath cmd [1] returns the path only if the subvolume creation is successful and is ready to use, it doesn't return otherwise. Could getpath cmd1 be used for the CSI requirement ? Or the CSI needs to know the size, data pool, and other metadata for other purposes as well?
[1] "fs subvolume getpath <vol_name> <sub_name> [<group_name>] "
Thanks,
Kotresh HR
Updated by Venky Shankar about 4 years ago
Kotresh Hiremath Ravishankar wrote:
Hi Shyam,
I have discussed this tracker with Venky and require clarification. The requirement to check the size and data pool is to know whether the subvolume creation is successful and ready to use? If that's the only case, the getpath cmd [1] returns the path only if the subvolume creation is successful and is ready to use, it doesn't return otherwise. Could getpath cmd1 be used for the CSI requirement ? Or the CSI needs to know the size, data pool, and other metadata for other purposes as well?
getpath will return -EAGAIN when the subvolume (or clone) is not ready for use. This is done here: https://github.com/ceph/ceph/blob/master/src/pybind/mgr/volumes/fs/operations/versions/subvolume_v1.py#L126
[1] "fs subvolume getpath <vol_name> <sub_name> [<group_name>] "
Thanks,
Kotresh HR
Updated by Shyamsundar Ranganathan about 4 years ago
Venky Shankar wrote:
Kotresh Hiremath Ravishankar wrote:
Hi Shyam,
I have discussed this tracker with Venky and require clarification. The requirement to check the size and data pool is to know whether the subvolume creation is successful and ready to use? If that's the only case, the getpath cmd [1] returns the path only if the subvolume creation is successful and is ready to use, it doesn't return otherwise. Could getpath cmd1 be used for the CSI requirement ? Or the CSI needs to know the size, data pool, and other metadata for other purposes as well?
The need is not to determine if the subvolume exists, but its attributes. This is to match if the subvolume that is found satisfies the request in terms of size, which data pool is chosen, and other related attributes.
There are times when a subvolume creation maybe interrupted, post which we will (using the CSI journal in RADOS) determine the name of the subvolume, at this point we need to read additional meta-data regarding the subvolume to ensure it fits the current request, or is a name/attribute conflict with the original request that may have been interrupted.
Updated by Kotresh Hiremath Ravishankar about 4 years ago
- Status changed from New to In Progress
- Pull request ID set to 34210
Updated by Jos Collin about 4 years ago
- Status changed from In Progress to Fix Under Review
Updated by Greg Farnum about 4 years ago
- Status changed from Fix Under Review to Pending Backport
Updated by Ramana Raja about 4 years ago
- Copied to Backport #45180: octopus: pybind/mgr/volumes: add command to return metadata regarding a subvolume added
Updated by Ramana Raja about 4 years ago
- Copied to Backport #45181: nautilus: pybind/mgr/volumes: add command to return metadata regarding a subvolume added
Updated by Nathan Cutler almost 4 years ago
- Status changed from Pending Backport to Resolved
While running with --resolve-parent, the script "backport-create-issue" noticed that all backports of this issue are in status "Resolved" or "Rejected".