-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
csi: dynamic plugins don't become available until next fingerprint #7296
Comments
The fingerprinting updates in #7386 have made a big improvement in this timing but it could still be faster. I'm going to mark this as an improvement to complete after we ship the beta. |
Some clarification on the current impact: when an alloc for a CSI plugin is placed, the This is primarily an impact to operators when first launching a plugin for a given Nomad client, including adding new clients to the cluster or when upgrading a plugin in place. (It also makes local development a bit tedious if you're frequently adding/removing plugins, but that primarily impacts Nomad team developers.) |
Now that #8699 has landed and we have an accurate view of expected plugin counts, I've been able to verify the timing behaviors here. The node update is edge-triggered, so client state changes from the plugin registration are happening immediately. The source of the remaining delay is the gap between the taskrunner's |
I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues. |
When a CSI plugin job is run, it's registered as a dynamic plugin as soon as the plugin supervisor hook gets a OK response back from
PluginProbe
. But the plugin's capabilities aren't fingerprinted until the dynamic plugin manager's fingerprint loop fires, which can be ~30s later. This causes a delay in availability of plugins to serve other CSI operations.(Note: this is an optimization issue and not a correctness issue.)
The text was updated successfully, but these errors were encountered: