Skip to content

Clarify that plugin may return OK for ControllerUnpublish if node or volume not found #375

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

Merged
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 3 additions & 2 deletions spec.md
Original file line number Diff line number Diff line change
Expand Up @@ -1257,6 +1257,7 @@ This RPC is typically called by the CO when the workload using the volume is bei

This operation MUST be idempotent.
If the volume corresponding to the `volume_id` is not attached to the node corresponding to the `node_id`, the Plugin MUST reply `0 OK`.
If the volume corresponding to the `volume_id` or the node corresponding to `node_id` cannot be found by the Plugin and the volume can be safely regarded as ControllerUnpublished from the node, the plugin SHOULD return `0 OK`.
If this operation failed, or the CO does not know if the operation failed or not, it can choose to call `ControllerUnpublishVolume` again.

```protobuf
Expand Down Expand Up @@ -1292,8 +1293,8 @@ The CO MUST implement the specified error recovery behavior when it encounters t

| Condition | gRPC Code | Description | Recovery Behavior |
|-----------|-----------|-------------|-------------------|
| Volume does not exist | 5 NOT_FOUND | Indicates that a volume corresponding to the specified `volume_id` does not exist. | Caller MUST verify that the `volume_id` is correct and that the volume is accessible and has not been deleted before retrying with exponential back off. |
| Node does not exist | 5 NOT_FOUND | Indicates that a node corresponding to the specified `node_id` does not exist. | Caller MUST verify that the `node_id` is correct and that the node is available and has not been terminated or deleted before retrying with exponential backoff. |
| Volume does not exist and volume not assumed ControllerUnpublished from node | 5 NOT_FOUND | Indicates that a volume corresponding to the specified `volume_id` does not exist and is not assumed to be ControllerUnpublished from node corresponding to the specified `node_id`. | Caller MUST verify that the `volume_id` is correct and that the volume is accessible and has not been deleted before retrying with exponential back off. |
| Node does not exist and volume not assumed ControllerUnpublished from node | 5 NOT_FOUND | Indicates that a node corresponding to the specified `node_id` does not exist and the volume corresponding to the specified `volume_id` is not assumed to be ControllerUnpublished from node. | Caller MUST verify that the `node_id` is correct and that the node is available and has not been terminated or deleted before retrying with exponential backoff. |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Part of the reason for this change is that the current Kubernetes handling of this is wrong to accommodate that. However, even after this change, as specified,the plugin SHOULD return '0 OK' means SP could return NOT_FOUND and per the error code Recovery Behavior the Caller MUST verify that the '..._id' is correct... before retrying with exponential backoff -- which caller can not do because it has no way to be able to verify if a given node or volume still exist. Therefore, we should either loosen the Recovery Behavior to Caller SHOULD verify..., but really this is something that we will need to fix in CSI 2.0 -- NOT_FOUND should not be allowed as an error code, and the SP MUST return OK if volume or node are gone and effectively detached.



#### `ValidateVolumeCapabilities`
Expand Down