Change:
Let's assume this scenario: linux node, zone A, tainted windows node, zone B, untainted In a multizone cluster, while trying to run the generic ephemeral volume tests in Windows nodes it might be possible that a volume that's supposed to be for a Windows node is created in the zone for the Linux node instead. The generic ephemeral storage tests use : [Testpattern: Generic Ephemeral-volume (default fs) (late-binding)] ephemeral [Testpattern: Generic Ephemeral-volume (default fs) (immediate)] ephemeral [Testpattern: Generic Ephemeral-volume (block volmode) (late-binding)] ephemeral This issue is happening because we're using the immediate testpattern which is not compatible with a multizone cluster. /kind failing-test /sig storage
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
I think "immediate" binding in general won't work in a multi-zone cluster. What do we do for other tests that explicitly specify immediate mode?
I think nothing special in any of the tests besides , it's just another test pattern that's tested
Do you see failures of other "immediate" mode tests? I'm wondering if there is some logic to detect and automatically skip those tests
that was the only failure, after I the skip I didn't see any other testpatterns that failed with "immediate" mode in other test groups.
I checked tests that passed with VolumeBindingMode immediate which are found in the topology tests, the topology tests detect if the testdriver has the field set to work and modify the clone of the StorageClass adding the field to it, I'm going to do the same for the Generic Ephemeral Volume tests.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Reopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close not-planned [1]:
Closing this issue, marking it as "Not Planned". <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closedReopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] Instructions 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

Discussion:
resource *storageframework.VolumeResource } var ( <ins> dInfo   = driver.GetDriverInfo() </ins> eDriver storageframework.EphemeralTestDriver l       local )

e2eskipper.Skipf("Cluster doesn't support %q volumes -- skipping", pattern.VolType) } } <ins> // A driver might support the Topology capability which is incompatible with the VolumeBindingMode immediate because // volumes might be provisioned immediately in a different zone to where the workload is located. if pattern.BindingMode == storagev1.VolumeBindingImmediate && len(dInfo.TopologyKeys) > 0 { e2eskipper.Skipf("VolumeBindingMode immediate is not compatible with a multi-topology environment.") } </ins> l = local{}