-
Notifications
You must be signed in to change notification settings - Fork 554
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ‘subvolumegroup’ field in cephfs storageclass #1884
Comments
This is already supported in configmap ceph-csi/examples/csi-config-map-sample.yaml Lines 37 to 39 in 0d9cb96
|
Thanks a lot! That's exactly what I want. |
Hi, again. Currently, clusterID and cephFS can be specified in storageclass. Likewise, if a user can specify SVG in storageclass, a SV can be created in the cephfs path that the user wants. What do you think of this approach? I think this feature to separate the cephfs path by different tenants or services is needed to support QoS. |
setting the SVG at storageclass is not possible as the storageclass parameters are not sent to the cephcsi In deleteVolume or deleteSnapshot operations. for that the SVG is moved to the configmap. if you want multiple SVG in single cluster you can create configmap like below [
{
"clusterID": "abcd", # this need to be specified in storageclass
"monitors": [
"10.20.30.40:6879",
],
"cephFS": {
"subvolumeGroup": "test"
}
},
{
"clusterID": "xyz", # this need to be specified in storageclass
"monitors": [
"10.20.30.40:6879",
],
"cephFS": {
"subvolumeGroup": "testing_123"
}
},
{
"clusterID": "klm", # this need to be specified in storageclass
"monitors": [
"10.20.30.40:6879",
],
"cephFS": {
"subvolumeGroup": "testing_svg"
}
}
] |
You're right. I thought it a little tricky that pointing the same ceph cluster using a different clusterID in configmap. But I didn't know this detail before.
Thanks a lot for your comment. I'm gonna update docs for others. |
closing this one, as its already covered in configmap. |
|
CephFS has a directory structure like ’/{volume}/{SVG}/{SV}.
Currently, SVG is fixed as
csi
for all pvc.e.g., ‘/vol/csi/pvc-1’ , ‘vol/csi/pvc-2’.
I think adding a SVG field in storageclass is necessary.
So the parent directory in which the SV is created could be classified by storageclass.
This makes it easy for multiple MDSs to process metadata in SVG.
I wonder if these features are in the plan.
I'm willing to create a PR for this issue.
The text was updated successfully, but these errors were encountered: