dynamic host volumes: ensure unique name per node #24748
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
users may modify an existing volume (probably to change the size? why else?) by setting an `id` in the volume spec and re-issuing create
with the same name -- the static vol is discarded, dynamic takes precedence, and log to warn the user
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Volume name must be unique per node.
For existing static host vols, the scheduler will prevent creation of duplicate names ("no node meets constraints"), and it will similarly prevent duplicate dynamic vols after fingerprint (node re-registration), but we need to prevent concurrent duplicate creation that may happen within a fingerprint interval, too.
Here a lock is set for name+id during
Create(and restore), then released whenDeleted to prevent such very-fast or concurrent creates.If the a volume spec is submitted again with a valid
idset, it can still update the volume, and the plugin'sCreatewill be run with the new spec. I'm guessing that folks may want to do this if either A) the plugin has been updated and folks want to regenerate their vols in place? or B) to increase the vol size (in CSI parlance, "expand"). Not sure if perhaps any other reasons, but I wanted to leave this door open.A last funny caveat is if a static host volume is added to agent config after a dynamic one has been created, and the agent restarted to use it, the dynamic one will take precedence. A warning is logged to inform the user if this happens.