jdef
commented
2 years ago The controller-unpublish call does not relay state on purpose. Consider that the CO is braindead and loses context. It should still be possible to unpublish.
I'm sympathetic to the partitioning problem, and think that the CO should do more to help plugins deal with such.
-1 on this proposal.
On Fri, Nov 5, 2021, 4:36 PM Sumukh Shivaprakash @.***> wrote:
Problem Overview:
ControllerPublishVolume has a contract to return FAILED_PRECONDITION with the status indicating the node id that the volume is currently published on. This helps detecting stale ControllerPublishVolume API calls by the CO to the SP controller and take appropriate action.
However, during the controller unpublish, consider the following ordering of events:
1.
CO issues a ControllerUnpublishVolume(node1) to the Plugin. 2.
The above TCP message is delayed indefinitely over the network. 3.
Node on which CO is running experiences a network partition and is not part of a federated cluster anymore. As a result, the CO is now running in a different node that decides to place it on node2. NOTE that the old TCP connection from the CO is still alive to the Plugin. 4.
CO issues ControllerPublishVolume(node2) to the Plugin. 5.
CO then decides to place the volume on node1 again hence issues ControllerUnpublishVolume(node2) subsequently doing a ControllerPublishVolume(node1). 6.
Finally, the delayed TCP message from 2 arrives indicating a ControllerUnpublishVolume(node1)
Expectation:
The Plugin must be able to identify the stale API call that comes in step 6 and ignore it. Proposal:
If the ControllerUnpublishVolume includes the original publish context that was returned as part of the ControllerPublishVolume, the Plugin/SP can sequence these and detect staless.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/container-storage-interface/spec/issues/496, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAR5KLBTVPDVDLJRE6OI2UDUKRE6ZANCNFSM5HOU3QLQ . 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.
sumukhs
Problem Overview:
ControllerPublishVolume has a contract to return FAILED_PRECONDITION with the status indicating the node id that the volume is currently published on. This helps detecting stale ControllerPublishVolume API calls by the CO to the SP controller and take appropriate action.
However, during the controller unpublish, consider the following ordering of events:
CO issues a ControllerUnpublishVolume(node1) to the Plugin.
The above TCP message is delayed indefinitely over the network.
Node on which CO is running experiences a network partition and is not part of a federated cluster anymore. As a result, the CO is now running in a different node that decides to place it on node2. NOTE that the old TCP connection from the CO is still alive to the Plugin.
CO issues ControllerPublishVolume(node2) to the Plugin.
CO then decides to place the volume on node1 again hence issues ControllerUnpublishVolume(node2) subsequently doing a ControllerPublishVolume(node1).
Finally, the delayed TCP message from 2 arrives indicating a ControllerUnpublishVolume(node1)
Expectation:
The Plugin must be able to identify the stale API call that comes in step 6 and ignore it.
Proposal:
If the ControllerUnpublishVolume includes the original publish context that was returned as part of the ControllerPublishVolume, the Plugin/SP can sequence these and detect staless.