Clarify NOT_FOUND returned from ControllerUnpublishVolumeRequest

[jsafrane]

The spec says that NOT_FOUND means that a volume (or node) corresponding to the specified volume_id (node_id) does not exist.

But it does not say what does it mean to CO. When CO is sure that it sent the right IDs and something else must have deleted the volume or node, can CO assume that the volume was detached from the node automatically by SP when the volume/node was deleted? In this case, returning OK would have the same meaning - the volume has been unpublished and CO does not need to do anything.

CO has no way how to check / fix attachment of deleted volumes (or nodes), so it cannot do any cleanup when NOT_FOUND is returned.

[msau42]

NOT_FOUND handling is more relevant to Unpublish right?

[davidz627]

I would suggest that the SP should decide (based on behavior of the storage system) whether the node or volume being deleted means:

1. The volume/node is assumed to be detached - return OK
2. The volume/node may not be detached - return NOT_FOUND - CO has no remedying solution besides retrying (?)

The thinking here is because there may be a case where the node/volume is temporarily not found and not assumed as detached.

If the SP can reasonably assume the disk has been detached then this is not an error, it can simply return OK

[jsafrane]

Yeah, sorry, I meant Unpublish

[saad-ali]

Discussed at community meeting. Notes here.

Conclusion: seems like a good idea. Clarify backwards compatibility plan. And then feel free to open PR. Would need to put prominent release note when this goes out.