-
Notifications
You must be signed in to change notification settings - Fork 332
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
distributed provisioning: dedicated check for "incompatible topology" #613
Comments
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
/remove-lifecycle stale |
/assign |
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:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
As discussed in #612 (comment), the usage of
GenerateAccessibilityRequirements
in the following code could be improved:https://github.com/pohly/external-provisioner/blob/f262e0f93ce2c172ac22f54978bbb9aff7f59d21/pkg/controller/controller.go#L1296-L1320
It works because the function is expected to only fail when the storage class topology is not compatible with the current node, but that is not obvious.
Options to make it more obvious:
GenerateAccessibilityRequirements
which checks the topology orGenerateAccessibilityRequirements
and check for thatThe text was updated successfully, but these errors were encountered: