Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1806266 - Require an extension to the cephfs subvolume commands, that can return metadata regarding a subvolume
Summary: Require an extension to the cephfs subvolume commands, that can return metada...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenShift Container Storage
Classification: Red Hat
Component: ceph
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: OCS 4.6.0
Assignee: Venky Shankar
QA Contact: Jilju Joy
URL:
Whiteboard:
Depends On: 1835216
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-02-23 13:09 UTC by Shyamsundar
Modified: 2020-12-17 06:22 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-12-17 06:22:27 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Ceph Project Bug Tracker 44277 0 None None None 2020-02-25 08:55:30 UTC
Red Hat Product Errata RHSA-2020:5605 0 None None None 2020-12-17 06:22:58 UTC

Description Shyamsundar 2020-02-23 13:09:39 UTC
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.

Comment 4 Michael Adam 2020-03-11 18:10:16 UTC
Why are we creating an RFE BZ (this is certainly an RFE)?
This planning/tracking should happen in Jira, afaict.

@Shyam?

(Apart from that, i don't think this is 4.4 material, since the ceph version to be used for 4.4 is probably locked at least for RFEs at this point?)

Comment 5 Shyamsundar 2020-03-11 18:58:48 UTC
(In reply to Michael Adam from comment #4)
> Why are we creating an RFE BZ (this is certainly an RFE)?
> This planning/tracking should happen in Jira, afaict.

Here is where this is tracked in Jira: https://issues.redhat.com/browse/RHSTOR-833

Further, there is an open cephfs tracker upstream for the same: https://tracker.ceph.com/issues/44277

The Ceph RFE bug was initially created to track the request with the CephFS team, but the upstream tracker is deemed good enough for the same.

> 
> @Shyam?

Do we need to close this and use Jira for the enhancement? Are there other Ceph enhancements being tracked in Jira? (I do not want to be the only one filing away a jira ticket for Ceph)

> 
> (Apart from that, i don't think this is 4.4 material, since the ceph version
> to be used for 4.4 is probably locked at least for RFEs at this point?)

Comment 6 Yaniv Kaul 2020-05-17 08:07:32 UTC
This doesn't seem to be properly triaged.

Comment 8 Michael Adam 2020-06-26 13:23:18 UTC
I think this is the ceph bug that this is tracking: BZ #1835216

This is ON_QA for RHCS 4.1 z1.



Remember that the sole purpose of the (In reply to Shyamsundar from comment #5)
> 
> Here is where this is tracked in Jira:
> https://issues.redhat.com/browse/RHSTOR-833
> 
> Further, there is an open cephfs tracker upstream for the same:
> https://tracker.ceph.com/issues/44277
> 
> The Ceph RFE bug was initially created to track the request with the CephFS
> team, but the upstream tracker is deemed good enough for the same.

The sole purpose of the ceph component of OCS is to track BZs in RHCS.

> Do we need to close this and use Jira for the enhancement? Are there other
> Ceph enhancements being tracked in Jira? (I do not want to be the only one
> filing away a jira ticket for Ceph)

Well, the ceph change is part of the items needed for the snapshot jira epic.
If people want a BZ for it, for tracking the change in RHCS, we can do it.

Approving for 4.6 since this is where we'll be landing snapshot and consuming this ceph release.

Comment 9 Yaniv Kaul 2020-07-12 11:59:43 UTC
The Ceph bug is already ON_QA. Moving to POST just to indicate it's in good progress and we should move to ON_QA as soon as we take that Ceph build.

Comment 11 Neha Berry 2020-09-16 12:49:52 UTC
@shyam these are the attributes we see with OCS -ocs-operator.v4.6.0-562.ci

sh-4.4# ceph version
ceph version 14.2.8-91.el8cp (75b4845da7d469665bd48d1a49badcc3677bf5cd) nautilus (stable)



sh-4.4# ceph fs subvolume info   ocs-storagecluster-cephfilesystem csi-vol-4e8e34ab-f80d-11ea-a26d-0a580a800211 --group_name csi
{
    "atime": "2020-09-16 11:11:03",
    "bytes_pcent": "0.13",
    "bytes_quota": 107374182400,
    "bytes_used": 135263372,
    "created_at": "2020-09-16 11:11:03",
    "ctime": "2020-09-16 11:44:47",
    "data_pool": "ocs-storagecluster-cephfilesystem-data0",
    "gid": 0,
    "mode": 16895,
    "mon_addrs": [
        "172.30.30.71:6789",
        "172.30.17.112:6789",
        "172.30.54.109:6789"
    ],
    "mtime": "2020-09-16 11:44:47",
    "path": "/volumes/csi/csi-vol-4e8e34ab-f80d-11ea-a26d-0a580a800211/a072d544-0f37-4502-bbd3-ec0a18895375",
    "pool_namespace": "",
    "type": "subvolume",
    "uid": 0
}


I still do not see the requested "- Size (or quota set)" ...can you please have a look? Also, can you explicitly specify the commands we need to test before moving the BZ to verified? The ceph bug doesnt have details of all the commands which got this change.


@Jilju, can you also try snapshot for CephFS volume and check the command output as well ?

"ceph fs subvolume snapshot"

Comment 12 Shyamsundar 2020-09-16 12:55:14 UTC
(In reply to Neha Berry from comment #11)
>     "bytes_quota": 107374182400,

> I still do not see the requested "- Size (or quota set)" ...can you please
> have a look? Also, can you explicitly specify the commands we need to test
> before moving the BZ to verified? The ceph bug doesnt have details of all
> the commands which got this change.

The above field reflects the quota.

Comment 13 Neha Berry 2020-09-16 13:49:39 UTC
(In reply to Shyamsundar from comment #12)
> (In reply to Neha Berry from comment #11)
> >     "bytes_quota": 107374182400,
> 
> > I still do not see the requested "- Size (or quota set)" ...can you please
> > have a look? Also, can you explicitly specify the commands we need to test
> > before moving the BZ to verified? The ceph bug doesnt have details of all
> > the commands which got this change.
> 
> The above field reflects the quota.

ack. In that case, are we good with all the requirements ?

Also, is there any other command one needs to verify apart from the "ceph fs subvolume snapshot" info ? Let us know.

if not, then once Jilju verifies the snapshot info, we would mark this BZ as verified.

Comment 14 Shyamsundar 2020-09-16 13:58:48 UTC
(In reply to Neha Berry from comment #13)
> (In reply to Shyamsundar from comment #12)
> > (In reply to Neha Berry from comment #11)
> > >     "bytes_quota": 107374182400,
> > 
> > > I still do not see the requested "- Size (or quota set)" ...can you please
> > > have a look? Also, can you explicitly specify the commands we need to test
> > > before moving the BZ to verified? The ceph bug doesnt have details of all
> > > the commands which got this change.
> > 
> > The above field reflects the quota.
> 
> ack. In that case, are we good with all the requirements ?

As it stands for OCS/Ceph-CSI the needed fields are present.

> 
> Also, is there any other command one needs to verify apart from the "ceph fs
> subvolume snapshot" info ? Let us know.

For snapshots, we have the size, created_at, data_pool, and has_pending_clones in the info return, which are again sufficient for Ceph-CSI to function.

> 
> if not, then once Jilju verifies the snapshot info, we would mark this BZ as
> verified.

Comment 15 Jilju Joy 2020-09-24 17:56:29 UTC
(In reply to Shyamsundar from comment #14)
> (In reply to Neha Berry from comment #13)
> > (In reply to Shyamsundar from comment #12)
> > > (In reply to Neha Berry from comment #11)
> > > >     "bytes_quota": 107374182400,
> > > 
> > > > I still do not see the requested "- Size (or quota set)" ...can you please
> > > > have a look? Also, can you explicitly specify the commands we need to test
> > > > before moving the BZ to verified? The ceph bug doesnt have details of all
> > > > the commands which got this change.
> > > 
> > > The above field reflects the quota.
> > 
> > ack. In that case, are we good with all the requirements ?
> 
> As it stands for OCS/Ceph-CSI the needed fields are present.
> 
> > 
> > Also, is there any other command one needs to verify apart from the "ceph fs
> > subvolume snapshot" info ? Let us know.
> 
> For snapshots, we have the size, created_at, data_pool, and
> has_pending_clones in the info return, which are again sufficient for
> Ceph-CSI to function.


These parameters mentioned above are present in the snapshot info. Moving this bug to verified.

# ceph fs subvolume snapshot ls ocs-storagecluster-cephfilesystem csi-vol-52e33199-fe84-11ea-8199-0a580a81020e --group_name csi
[
    {
        "name": "csi-snap-b9a577ab-fe84-11ea-8199-0a580a81020e"
    }
]

# ceph fs subvolume snapshot info ocs-storagecluster-cephfilesystem csi-vol-52e33199-fe84-11ea-8199-0a580a81020e csi-snap-b9a577ab-fe84-11ea-8199-0a580a81020e --group_name csi
{
    "created_at": "2020-09-24 16:40:59.587143",
    "data_pool": "ocs-storagecluster-cephfilesystem-data0",
    "has_pending_clones": "no",
    "protected": "yes",
    "size": 1073741824
}

Tested in version:
# ceph version
ceph version 14.2.8-91.el8cp (75b4845da7d469665bd48d1a49badcc3677bf5cd) nautilus (stable)
ocs-operator.v4.6.0-98.ci
Cluster version is 4.6.0-0.nightly-2020-09-24-074159


> 
> > 
> > if not, then once Jilju verifies the snapshot info, we would mark this BZ as
> > verified.

Comment 18 errata-xmlrpc 2020-12-17 06:22:27 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: Red Hat OpenShift Container Storage 4.6.0 security, bug fix, enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:5605


Note You need to log in before you can comment on or make changes to this bug.