Right now, when using topology with this driver, it is required to use volumeBindingMode: WaitForFirstConsumer. If I understand correctly, this is so a pod's scheduling requirements can be taken into account while provisioning a volume, as the volume may otherwise be created in a topology inaccessible to the pod if the pod has strict scheduling requirements.
However, we run into the case where the PV is the only scheduling requirement for the Pod, it can otherwise run anywhere the PV is accessible. Needing WaitForFirstConsumer leads to a pod with a new PV sometimes scheduling on a node the PV cannot be mounted from, resulting in the Pod getting stuck in a Pending state. Deleting the Pod should fix the issue once #828 is fixed, as then the Pod will be scheduled on a node the PV is accessible.
I think the volumeBindingMode Immediate can be quite easily supported, with a small change to the get_volume_topologies function
|
if request.HasField(servers_settings.REQUEST_ACCESSIBILITY_REQUIREMENTS_FIELD): |
. It currently relies on the preferred topology setting to do any kind of topology handling, but extending it with 'pick a random or first available topology if no preferred topology is set' should be fairly simple.
Right now, when using topology with this driver, it is required to use volumeBindingMode: WaitForFirstConsumer. If I understand correctly, this is so a pod's scheduling requirements can be taken into account while provisioning a volume, as the volume may otherwise be created in a topology inaccessible to the pod if the pod has strict scheduling requirements.
However, we run into the case where the PV is the only scheduling requirement for the Pod, it can otherwise run anywhere the PV is accessible. Needing WaitForFirstConsumer leads to a pod with a new PV sometimes scheduling on a node the PV cannot be mounted from, resulting in the Pod getting stuck in a Pending state. Deleting the Pod should fix the issue once #828 is fixed, as then the Pod will be scheduled on a node the PV is accessible.
I think the volumeBindingMode Immediate can be quite easily supported, with a small change to the get_volume_topologies function
ibm-block-csi-driver/controllers/servers/utils.py
Line 50 in 926727b