ControllerGetVolume Volume does not exist is not an error instead its an abnormal true condition

[nb950]

"ControllerGetVolumeResponse should contain current information of a volume if it exists. If the volume does not exist any more, ControllerGetVolume should return gRPC error code NOT_FOUND"

refer discussion : https://kubernetes.slack.com/archives/C8EJ01Z46/p1635513340016300

Volume does not exist --should not be returned as an error in the response ,instead it should be returned as a volume_condition abnormal =true in ControllerGetVolumeResponse .
please help fix the spec

[jdef]

My interpretation of the slack thread is that maybe some k8s logic change is required. I don't agree with the proposal to change the spec here. Whether or not volume conditions are supported, a missing volume must be reported as NOT_FOUND.

…

-1 on this proposal

On Wed, Nov 3, 2021, 10:25 AM jai kumar ***@***.***> wrote: "ControllerGetVolumeResponse should contain current information of a volume if it exists. If the volume does not exist any more, ControllerGetVolume should return gRPC error code NOT_FOUND" refer discussion : [( https://kubernetes.slack.com/archives/C8EJ01Z46/p1635513340016300)] Volume does not exist --should not be returned as an error in the response ,instead it should be returned as a volume_condition abnormal =true in ControllerGetVolumeResponse . please help fix the spec — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#495>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAR5KLFBRV7ZSEOFHHSNNCTUKFH6RANCNFSM5HJB4UDA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[nb950]

jdef , please reconsider. This method is called by kubelet and external-health-monitor side-car , the response is checked to send events to PVC / POD if abnormal=true is set. If instead NOT_FOUND error is sent there is no event for it and k8s-admin is not alerted to this condition. refer
https://github.com/kubernetes/kubernetes/blob/master/pkg/volume/csi/csi_client.go https://github.com/kubernetes-csi/external-health-monitor/blob/master/pkg/csi-handler/pv_handler.go

[jdef]

My interpretation of the slack thread is that k8s makes certain decisions based on results of list-volumes in conjuction with results from subsequent get-volume calls. What prevents that logic from being updated to address the business case presented in slack? Maybe restate the business case here for clarity, to avoid misinterpretation?

…

On Sat, Nov 6, 2021, 8:55 AM jai kumar ***@***.***> wrote: jdef , please reconsider. This method is called by kubelet and external-health-monitor side-car , the response is checked to send events to PVC / POD if abnormal=true is set. If instead NOT_FOUND error is sent there is no event for it and k8s-admin is not alerted to this condition. refer https://github.com/kubernetes/kubernetes/blob/master/pkg/volume/csi/csi_client.go https://github.com/kubernetes-csi/external-health-monitor/blob/master/pkg/csi-handler/pv_handler.go — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#495 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAR5KLGEC2VG2SUKCFLKHJTUKUXVBANCNFSM5HJB4UDA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[nb950]

the usecase is to report an abnormal event on a POD/PVC like volume not found . in all the other csi calls reporting an error if volume is not found is expected and it is the norm. in get-volume call reporting health of the volume in response versus reporting error is desired.
if volume on the array is no longer usable method will return abnormal=true . if method is unable to determine status of the volume it will return error. does that help ?