-
Notifications
You must be signed in to change notification settings - Fork 4k
pkg/server: initialize tenant version setting in settings watcher #104859
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
Conversation
1bf758d to
7ddbcda
Compare
7ddbcda to
e1140bb
Compare
knz
left a comment
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.
This change is sound overall but note that this is currently unlikely to work well because we do not yet wait for all setting values to be received when a tenant server is initialized.
Look at (c *connector) Start() in kv/kvclient/kvtenant/connector.go. It starts the setting receiver (c.runTenantSettingsSubscription()) but it does not wait for the initial settings to have been received. So some code after the call to .Start() completes can still see the wrong/outdated values.
The proper fix in combination to your PR is to add a synchronization step there.
Reviewed 2 of 3 files at r1, all commit messages.
Reviewable status:complete! 0 of 0 LGTMs obtained (waiting on @jeffswenson, @smg260, and @srosenberg)
|
The issue I just described is this #96512 |
|
I think this PR will help, which you are welcome to review. #105566 |
knz
left a comment
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.
#105566 has merged you can rebase this on top of it.
Reviewed 1 of 3 files at r1.
Reviewable status:complete! 0 of 0 LGTMs obtained (waiting on @healthy-pod, @jeffswenson, @smg260, and @srosenberg)
pkg/server/settingswatcher/settings_watcher.go line 333 at r1 (raw file):
// Cluster version setting not initialized. if err := clusterversion.Initialize(ctx, newVersion.Version, &s.settings.SV); err != nil { log.Warningf(ctx, "failed to initialize cluster version setting: %s", err.Error())
May I suggest logcrash.ReportOrPanic here so it fails more loudly in tests thanks.
knz
left a comment
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.
Reviewable status:
complete! 0 of 0 LGTMs obtained (waiting on @healthy-pod, @jeffswenson, @smg260, and @srosenberg)
pkg/server/settingswatcher/settings_watcher.go line 333 at r1 (raw file):
Previously, knz (Raphael 'kena' Poss) wrote…
May I suggest
logcrash.ReportOrPanichere so it fails more loudly in tests thanks.
This might even need a log.Fatal. I don't think it would be safe to let the server start without a valid version setting.
This code change removes the early version setting initialization because it is not needed. Initialization now happens in the settings watcher during the initial scan when the tenant logical version is read from the settings table. The setting is only initialized if it's empty / not pre-initialized because some tests pre-initialize it. Release note: None Epic: none
e1140bb to
3b4e8f6
Compare
|
Ready for another look |
knz
left a comment
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.
Reviewed 2 of 2 files at r2, all commit messages.
Reviewable status:complete! 1 of 0 LGTMs obtained (waiting on @jeffswenson, @smg260, and @srosenberg)
|
bors r=knz |
|
Build failed (retrying...): |
|
Build failed (retrying...): |
|
Build succeeded: |
Previously, shared-process tenants would initialize their view of the cluster version early and set it to the `MinSupportedVersion` as a "safe" option. However, that setting can likely be wrong, especially now that we plan to support skip-version upgrades. In this commit, we remove that code and rely on the initialization that happens from storage in `preStart`. This means that we now expose a non-negligible amount of code to a state where we don't have an initialized cluster version. However, having that error out is better than have code assume a potentially wrong version. A similar discussion and approach happened for separate process tenants a while ago: see cockroachdb#100684 and cockroachdb#104859. Fixes: cockroachdb#126754 Release note: None
Previously, shared-process tenants would initialize their view of the cluster version early and set it to the `MinSupportedVersion` as a "safe" option. However, that setting can likely be wrong, especially now that we plan to support skip-version upgrades. In this commit, we remove that code and rely on the initialization that happens from storage in `preStart`. This means that we now expose a non-negligible amount of code to a state where we don't have an initialized cluster version. However, having that error out is better than have code assume a potentially wrong version. A similar discussion and approach happened for separate process tenants a while ago: see cockroachdb#100684 and cockroachdb#104859. Fixes: cockroachdb#126754 Release note: None
127170: server: do not initialize cluster version to minimum supported r=stevendanna a=renatolabs Previously, shared-process tenants would initialize their view of the cluster version early and set it to the `MinSupportedVersion` as a "safe" option. However, that setting can likely be wrong, especially now that we plan to support skip-version upgrades. In this commit, we remove that code and rely on the initialization that happens from storage in `preStart`. This means that we now expose a non-negligible amount of code to a state where we don't have an initialized cluster version. However, having that error out is better than have code assume a potentially wrong version. A similar discussion and approach happened for separate process tenants a while ago: see #100684 and #104859. Fixes: #126754 Release note: None Co-authored-by: Renato Costa <renato@cockroachlabs.com>
Previously, shared-process tenants would initialize their view of the cluster version early and set it to the `MinSupportedVersion` as a "safe" option. However, that setting can likely be wrong, especially now that we plan to support skip-version upgrades. In this commit, we remove that code and rely on the initialization that happens from storage in `preStart`. This means that we now expose a non-negligible amount of code to a state where we don't have an initialized cluster version. However, having that error out is better than have code assume a potentially wrong version. A similar discussion and approach happened for separate process tenants a while ago: see #100684 and #104859. Fixes: #126754 Release note: None
This code change removes the early version setting initialization
because it is not needed.
Initialization now happens in the settings watcher during the initial
scan when the tenant logical version is read from the settings table.
The setting is only initialized if it's empty / not pre-initialized
because some tests pre-initialize it.
Release note: None
Epic: CRDB-26691