-
-
Notifications
You must be signed in to change notification settings - Fork 39
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
Advertise the readiness of the driver on each node. #72
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! I'll let @maennchen give the final approval.
Can you please briefly explain/show how this would be used?
Hi, indeed I forgot to provide a use case. When pods get scheduled on freshly created nodes and the driver just started many pods will temporarily fail with Having the driver readiness signalled at node level with a label allow us to inject proper affinity/node selector in pods mounting csi-gcs volume and ensure pods only get scheduled after the driver is ready to mount volumes. This results in a smoother user experience. |
Great! Can you please rebase/merge master and add such info to https://github.com/ofek/csi-gcs/blob/master/docs/troubleshooting.md#todo (and rename header) |
Set the label gcs.csi.ofek.dev/driver-ready={true,false} on each node running a controller
3a4bf25
to
fc6cc3f
Compare
fc6cc3f
to
8c2f50d
Compare
I updated the documentation. If I have the time, and if you are interested, I can contribute the mutating webhook too in a separate PR. |
Yes please! |
…n if k8s implementation seems forgiveful.
This PR set the label
gcs.csi.ofek.dev/driver-ready={true,false}
on each node running csi-gcs to reflect the state of readiness of the driver.This allows pods to avoid nodes where csi-gcs is still starting up.