-
Notifications
You must be signed in to change notification settings - Fork 2k
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
ephemeral disk: migrate
should imply sticky
#16826
Merged
Merged
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
The `ephemeral_disk` block's `migrate` field allows for best-effort migration of the ephemeral disk data to new nodes. The documentation says the `migrate` field is only respected if `sticky=true`, but in fact if client ACLs are not set the data is migrated even if `sticky=false`. The existing behavior when client ACLs are disabled has existed since the early implementation, so "fixing" that case now would silently break backwards compatibility. Additionally, having `migrate` not imply `sticky` seems nonsensical: it suggests that if we place on a new node we migrate the data but if we place on the same node, we throw the data away! Update so that `migrate=true` implies `sticky=true` as follows: * The failure mode when client ACLs are enabled comes from the server not passing along a migration token. Update the server so that the server provides a migration token whenever `migrate=true` and not just when `sticky=true` too. * Update the scheduler so that `migrate` implies `sticky`. * Update the client so that we check for `migrate || sticky` where appropriate. * Refactor the E2E tests to move them off the old framework and make the intention of the test more clear.
tgross
force-pushed
the
drain-migrate-no-sticky
branch
from
April 7, 2023 14:50
d820318
to
5e97aea
Compare
tgross
changed the title
drain:
ephemeral disk: Apr 7, 2023
migrate
should imply sticky
migrate
should imply sticky
schmichael
approved these changes
Apr 7, 2023
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.
Looks great!
tgross
added a commit
that referenced
this pull request
Apr 12, 2023
The `ephemeral_disk` block's `migrate` field allows for best-effort migration of the ephemeral disk data to new nodes. The documentation says the `migrate` field is only respected if `sticky=true`, but in fact if client ACLs are not set the data is migrated even if `sticky=false`. The existing behavior when client ACLs are disabled has existed since the early implementation, so "fixing" that case now would silently break backwards compatibility. Additionally, having `migrate` not imply `sticky` seems nonsensical: it suggests that if we place on a new node we migrate the data but if we place on the same node, we throw the data away! Update so that `migrate=true` implies `sticky=true` as follows: * The failure mode when client ACLs are enabled comes from the server not passing along a migration token. Update the server so that the server provides a migration token whenever `migrate=true` and not just when `sticky=true` too. * Update the scheduler so that `migrate` implies `sticky`. * Update the client so that we check for `migrate || sticky` where appropriate. * Refactor the E2E tests to move them off the old framework and make the intention of the test more clear.
tgross
added a commit
that referenced
this pull request
Apr 12, 2023
tgross
added a commit
that referenced
this pull request
Apr 12, 2023
tgross
added a commit
that referenced
this pull request
Apr 12, 2023
tgross
added a commit
that referenced
this pull request
Apr 12, 2023
tgross
added a commit
that referenced
this pull request
Apr 12, 2023
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.
The
ephemeral_disk
block'smigrate
field allows for best-effort migration of the ephemeral disk data to new nodes. The documentation says themigrate
field is only respected ifsticky=true
, but in fact if client ACLs are not set the data is migrated even ifsticky=false
.The existing behavior when client ACLs are disabled has existed since the early implementation, so "fixing" that case now would silently break backwards compatibility. Additionally, having
migrate
not implysticky
seems nonsensical: it suggests that if we place on a new node we migrate the data but if we place on the same node, we throw the data away!Update so that
migrate=true
impliessticky=true
as follows:migrate=true
and not just whensticky=true
too.migrate
impliessticky
.migrate || sticky
where appropriate.Fixes #12314
E2E test results: