-
Notifications
You must be signed in to change notification settings - Fork 336
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[release-1.2] Introduce new flag - strict-topology #288
Conversation
With the current implementation, In delayed binding case, CSI driver is offered with all nodes topology that are matched with 'selected node' topology keys in CreateVolumeRequest.AccessibilityRequirements. So this allows the driver to select any node from the passed preferred list to create volume. But this results in scheduling failure when the volume created on a node other than Kubernetes selected node. To address this, introduced new flag "--strict-topology', when set, in case of delayed binding, the driver is offered with only selected node topology, so that driver has to create the volume on this node. Modified tests so that now every test is run with and without 'strict topology'.
Hi @avalluri. Thanks for your PR. I'm waiting for a kubernetes-csi or kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/ok-to-test |
/lgtm As a sanity check, given that hostpath doesn't implement topology, I want to first run the pd e2es on a multi-zone cluster to make sure this hasn't caused any regressions |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: avalluri, msau42 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Tested manually with repd /hold cancel |
master: update release-tools
Backport #282 to release-1.2
What type of PR is this?
/kind bug
/kind design
What this PR does / why we need it:
Allows the driver to support delayed binding properly.
Which issue(s) this PR fixes:
Fixes #221
Does this PR introduce a user-facing change?: