-
Notifications
You must be signed in to change notification settings - Fork 321
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
Adding PVC's annotation to CreateVolumeRequest.Parameters #86
Comments
I second this request, and we discussed this idea with @saad-ali at this week's Storage SIG F2F. The chief concern is name collisions between storage class parameters and PVC annotations. Saad suggested this capability be gated via a startup flag. @orainxiong, are you planning to submit a PR for this? |
@clintonk Thx for your replay.
Note : Reverse key name
The advantage of implementation hardly modifies existing |
While I agree that there should be a way how to pass parameters from user to
|
After creating the I'm using the name of the request ot create the volumes, which ends up being the I thought maybe I can use the
and then in the volumeName := req.Name
// change the name if the storage-class has a prefix option
prefix, ok := req.Parameters["volumePrefix"]
if ok {
volumeName = prefix + "-" + volumeName
} This allows me to create a volume based on this users CSI deployment. However, this is not scalable because:
A better idea would be to use the We're already passing down the information from a Kubernetes resource (i.e |
check this out: |
@sbezverk thanks for the tip, I didn't know it. Though, the prefix was just an example, it could be also something else. Such tagging the resource on the cloud provider side based on the created PVC labels. |
@jsafrane If I understand correctly, I notice that external-provisioner has exposed
End storage drivers can get I very agree with your opinion. It's a temporary solution which makes storage driver Looking forward to your suggestions. |
@fatih, for tagging we could perhaps extend CSI's CO would provide generic
@orainxiong, that's intentional. I could imagine our CSI provisioner passes content of some alpha annotations from PVC as |
I think passing the
I'm not sure how to pass them via CO though. a
I know that Kubernetes annotations mostly store data like this and it's a common thing there.
Yeap. Attaching is only one of the things the CSI driver can accomplish. Changing the name is another action it should be allowed to do. |
@jsafrane Thanks. I got it. I will close this issue. |
Why is this closed? Did we have a PR that fixes this issue or a solution that is applicable right now? |
At least, in my opinion, there is a temporary way to handle this issue. But, it isn't applicable for all COs that support CSI. As your suggestions, a new function
On the storage provisioner side, they can decode parameters from |
@orainxiong Thanks for the reply. The title says |
@fatih ok, you're right. : - ) |
Has injectCOParameter() already been merged to external-provisioner? |
@mkimuram |
@orainxiong I tested your code as below and confirmed that annotationsPVC and labelsPVC were added to parameters that are passed to each driver. In my opinion, there would be still rooms for discussion to make this code merged:
I found a related discussion below for 3, and this will be needed to be discussed, first . Any comments for this issue? @jsafrane @princerachit @vladimirvivien Summary of test Results:
[With patch]
Please see below for how I tested: [Without patch] (Also see [files] below for csi-sc2.yaml and csi-pvc2.yaml.)
[With patch] (Also see [files] below for csi-sc2.yaml and csi-pvc2.yaml.)
[Files]
|
@mkimuram today's discussion concluded that we are not going to immediately touch the spec for CreateVolumeRequest to pass CO specific metadata(PVC name,PVC id etc). A proposed workaround is to write your own external provisioner which knows what params to pass for your specific driver. However, as pvc annotations are also used to add volume related information, adding them to external-provisioner would be possible. We need someone from k8s wg-csi to nod on this. @saad-ali |
@clintonk You're welcome. : - ) |
We've talked about this a bit in kubernetes/community#2273 as well. I'd like a way to have VolumeAttributes be passed in PVC's and the external provisioner can decide if its ok merging none/some/all of them with the StorageClasses VolumeAttributes when sending to the CSI drivers Create/DeleteVolume. And also if none/some/all should be copied to the resulting PV for the CSI driver's mount/unmount. This wouldn't be specific to Kubernetes, as they would be CSI attributes, not Kubernetes annotations. |
Is it the same logic to @orainxiong 's above code or different one? According to @princerachit 's below comment, at least pvc annotations could be allowed to be passed by above way, if k8s wg-csi agrees.
|
My current standing on this issue: Annotations on PVCs MUST NOT be passed to CSI drivers. The Kubernetes PVC object is intended for application portability. When we start leaking cluster/implementation specific details in to it we are violating that principle. And explicitly passing PVC annotations to CSI drivers encourages that pattern. Workload portability is a corner stone of Kubernetes. It is one of the major reasons for the success of the project. We must be very careful when we violate it. Instead let's focus on specific use cases. And let's see if we can come up with better solutions for each of those uses cases rather then opening up a hole in the API. |
@saad-ali There is a similar use case in my team: We support multiple storage types in a cluster, such as However, we also need to set quota for PVCs, so we need to set quota for these two |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle stale |
/lifecycle frozen |
This argument |
I need to map existing shares of NAS filers to PV without the cluster/storage admins intervention #kubernetes-csi/csi-driver-smb#398 hence placing the sharename in the PVC would be the solution to achieve this. If using an annotation is not suitable since it would break the CSI specs, would it be possible to use an extra parameter as described in #714 to pass parameters directly to the driver? |
This would also help to tag Azure file share/disk by overriding |
since passing pvc annotation to |
We're also in need of a feature like this to be able to associate disks with applications to better track costs. |
Store NodeID in annotation
This PR: #1239 |
As the title says, there is a great possibility that the application-specific
Operator
would leveragePVC
'sAnnotation
for storing custom data. The custom data will tell storage provisioner how CSI drive create volume correctly.Here is already existing logic for provision volume :
Note : more details
CSI Plugin specifies that
CreateVolumeRequest
's fieldParameters
isOPTIONAL
and opaque.What I am suggesting is that we could pass in
PVC
'sAnnotation
in addition toStorageclass.Parameter
.The text was updated successfully, but these errors were encountered: