#supportedTopologies "strictness"

1 messages · Page 1 of 1 (latest)

normal blaze
#

Hello,

We use the CSI topology feature to influence PV creation on the correct SVM on the right site and VLAN.
I wanted to ask whether Trident may still provision a PV although the topology of a chosen node by the scheduler is not in any of the supportedTopologies defined in the backends?
Is the supportedTopologies a hard requirement?

To provide more details:
The SC is in WaitForFirstConsumer and allows all topologies.
The backends support a subset of the existing topology labels on the nodes, meaning that there are some nodes, where no backend actually satisfies the topology labels.
When I create a Pod and it is by chance scheduled on one of the nodes which should not be supported, I was expecting Trident to give an error and to not provision the PV or that the scheduler would pick another node until provisioning succeeds.
But to my surprise, Trident provisioned the PV (I don't know to which logic, as it should not have provisioned it) and the Pod could not be scheduled afterwards, since the nodeAffinity labels of the resulting PV which were added by Trident do not match the selected node during scheduling.
The last part is an understandable consequence, but I don't get why the provisioning succeeded.

Many thanks for the help.
BR