choosing node for volume(s)

[pohly]

When creating a persistent volume, the user may want to specify on which node the volume is to be allocated. Currently this is random (= PMEM-CSI picks among the nodes which have free space). There is resistance against extending PVC with additional parameters because it is supposed to be a portable abstraction on top of a generic storage system. The suggested solution is to make late binding via WaitForFirstConsumer reliable (kubernetes-csi/external-provisioner#221 (comment)).

We should develop and submit a patch for that to external-provisioner. Problem: new features will be against master, which only supports topology on Kubernetes >= 1.14. Backport into the release-1.0 branch?

When implementing that we also need to consider what that means for cache volumes where nodes are specified in the StorageClass. For cache volumes, users can only choose the number of nodes, but not the nodes themselves. No good solution for that yet.

[avalluri]

Submitted PR for comments. The idea here is to add a new flag(-strict-topology), that handles the case of late binding and passes only selected node to CreateVolumeRequest.AccessibilityRequirements. So, PMEM-CSI considers only that node to create volume and returns with failure if not enough space without trying for other nodes in the cluster.

[pohly]

kubernetes-csi/external-provisioner#282 was merged. Next steps:

• tentatively change our deployment so that it uses the "canary" image of the provisioner and the -strict-topology flag
• create a storage class with delayed binding
• try it out
• cherry-pick the strict topology patch into the release-1.2 (upcoming release, urgent, for Kubernetes >= 1.14) and release-1.0 (Kubernetes 1.13)

[avalluri]

• cherry-pick the strict topology patch into the release-1.2 (upcoming release, urgent, for Kubernetes >= 1.14) and release-1.0 (Kubernetes 1.13)

Submitted kubernetes-csi/external-provisioner#288 for release-1.2

[avalluri]

@pohly I think we can close this issue. Do you agree?