Relax singleton-context constraint for pending non-singleton-context reverts#10114
Merged
shlomi-noach merged 7 commits intovitessio:mainfrom May 3, 2022
Conversation
Signed-off-by: Shlomi Noach <2607934+shlomi-noach@users.noreply.github.com>
Signed-off-by: Shlomi Noach <2607934+shlomi-noach@users.noreply.github.com>
Signed-off-by: Shlomi Noach <2607934+shlomi-noach@users.noreply.github.com>
shlomi-noach
added
Type: Enhancement
Contributor
Author
|
Call for review |
mattlord
reviewed
May 2, 2022
Member
mattlord
left a comment
mattlord
left a comment
There was a problem hiding this comment.
A couple of nits, but otherwise LGTM. We should at least change the single dashes to double for the new flag everywhere. Let me know what you think.
go/test/endtoend/onlineddl/singleton/onlineddl_singleton_test.go
Outdated
Show resolved
Hide resolved
go/vt/vttablet/onlineddl/executor.go
Outdated
Comment on lines
+3597
to
+3598
| revertedUUID, _ := pendingOnlineDDL.GetRevertUUID() | ||
| if revertedUUID == "" { |
Member
There was a problem hiding this comment.
This feels like an opportunity for undefined behavior in the future. Any reason not to do this instead?
if _, err := pendingOnlineDDL.GetRevertUUID(); errors.Is(err, vtrpcpb.Code_INVALID_ARGUMENT) {
Contributor
Author
There was a problem hiding this comment.
changed to if _, err := pendingOnlineDDL.GetRevertUUID(); err != nil ; I prefer not to rely on a specific error code.
Signed-off-by: Shlomi Noach <2607934+shlomi-noach@users.noreply.github.com>
Signed-off-by: Shlomi Noach <2607934+shlomi-noach@users.noreply.github.com>
Signed-off-by: Shlomi Noach <2607934+shlomi-noach@users.noreply.github.com>
Signed-off-by: Shlomi Noach <2607934+shlomi-noach@users.noreply.github.com>
Contributor
Author
|
no no, thank you |
shlomi-noach
deleted the
singleton-context-allow-reverts-without-single-context
branch
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Description
When a migration runs with -singleton-context ddl strategy flag, and with context
A, then another migration with-singleton-contextcan only be submitted if it has same contextA, and cannot be submitted if it has contextB. Note, the submission itself returns with an error.We want to have better user experience when it comes to reverts. Reverts may be long running and are allowed to run concurrently to other migrations.
A REVERT can run without a
-singleton-contextflag. In fact, this is the canonical way of running it. So we do not fail submitting a REVERT even if there are pending migrations.However, what happens when a REVERT is already running, and a new migration comes in?
Starting this PR, the following holds true:
-singleton-context-singleton-contextand with some arbitrarymigration_context.To clarify:
-singleton-contextflag with some-migration_context=A-singleton-contextflag may only be submitted it it also has-migration_context=A, and it will be rejected if it has-migration_context=BThe reason we add this relaxation is that we see an operational pattern in usage, and this behavior makes sense operationally.
Documentation to follow.
Related Issue(s)
-singleton-contextflag #7946Checklist