Change:
} sc.AllowedTopologies = newTopologies } <ins> sc.AllowedTopologies = t.replaceFailureDomainsToCSI(sc.AllowedTopologies) </ins> sc.Parameters = params

Discussion:
This test fails on Kubernetes cluster in "westus" region (without any number) and with CSI migration enabled: Error: failed to provision volume with StorageClass "e2e-topology-84vk7sp": error generating accessibility requirements: topology map[] from selected node "ci-op-9j1nby77--9zlwv-worker-westus-ljw4g" is not in requisite: [map[]] StorageClass generated by the test: PVC created by the test: <details</detailsLabels of the selected node: The external-provisioner does not even call the CSI driver and reports this event: The volume should get provisioned. See above, "westus" region with no availability zones seems to be the key. It looks like the translation from in-tree StorageClass to CSI one translates topology requirements to , but the CSI one expects <details</details<details</details<detailsOpenShift 4.10 </details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/priority important-soon cc
/sig storage
per https://kubernetes-, is not a zone, it's actually a fault-domain num. valid zone format is , could you change the storage class with setting, and try again? Thanks.
o, if "westus" region does not support zone, then I think you should test setting in another zone, make sure you have created a zoned node first.
I have as SC that works without CSI migration, with CSI migration it does not work. That's a regression. It should not matter if the SC is somehow odd. The labels are selected by test code, some other production code might use these labels too.
Out of curiosity, how reliable are zone numbers in Azure? I can see .. in a region with zones. If is used only in regions without a zone, then the translation can translate to , which the CSI driver expects.
I would say that's a wrong usage for zone.

following config would create a pv that could only be scheduled to a non-zone node with fault domain , if there is no node supports zone, then should not be set.
But nodes report that they are in , therefore it make sense to accept the same input in StorageClass.
if we translation "0" to "", then the pv created by that sc could be scheduled to any non zone node with any fault domain. That's a corner case that cluster is not in zone, and user still wants to set in sc
I am not sure I understand. If I provision a CSI volume in the westus cluster, its PV gets anyway: I have the cluster only with nodes in "westus" region, so all of them are without any zone. What would the CSI driver do if there were nodes in "westus" and say "ukwest", which does not have zones either? I can't test that setup easily, but I think the driver would report for both of them anyway, hence translating to does not make things worse, I think.
/sig storage /sig cloud-provider /area provider/azure
can you please check my previous comment? In what cases would be translating "0" to "" worse than the translation code we have today?
it's not worse or better, a single num () is actually not a valid zone, such in sc is actually not valid.
I mean we could translate the single digit to to make it work while the usage is wrong.
/sig storage
/sig cloud-provider