Skip to content

Conversation

@healthy-pod
Copy link
Contributor

@healthy-pod healthy-pod commented Jun 14, 2023

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

@cockroach-teamcity
Copy link
Member

This change is Reviewable

@healthy-pod healthy-pod force-pushed the move-version-init branch 2 times, most recently from 1bf758d to 7ddbcda Compare June 14, 2023 21:46
@healthy-pod healthy-pod marked this pull request as ready for review June 14, 2023 21:48
@healthy-pod healthy-pod requested review from a team as code owners June 14, 2023 21:48
@healthy-pod healthy-pod requested review from jeffswenson, knz, smg260 and srosenberg and removed request for a team June 14, 2023 21:48
Copy link
Contributor

@knz knz left a 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: :shipit: complete! 0 of 0 LGTMs obtained (waiting on @jeffswenson, @smg260, and @srosenberg)

@knz
Copy link
Contributor

knz commented Jun 15, 2023

The issue I just described is this #96512

@knz
Copy link
Contributor

knz commented Jun 26, 2023

I think this PR will help, which you are welcome to review. #105566

@knz knz added the backport-23.1.x PAST MAINTENANCE SUPPORT: 23.1 patch releases via ER request only label Jun 26, 2023
craig bot pushed a commit that referenced this pull request Jun 27, 2023
105566: kvtenant,settingswatcher: ensure overrides are applied during start r=yuzefovich a=knz

See individual commits for details.

Fixes #96512.
Needed to unblock #104859.
Epic: CRDB-26691

Co-authored-by: Raphael 'kena' Poss <knz@thaumogen.net>
Copy link
Contributor

@knz knz left a 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: :shipit: 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.

Copy link
Contributor

@knz knz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: :shipit: 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.ReportOrPanic here 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.

@knz knz added the A-multitenancy Related to multi-tenancy label Jun 27, 2023
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
@healthy-pod
Copy link
Contributor Author

Ready for another look

@healthy-pod healthy-pod requested a review from knz July 17, 2023 23:45
Copy link
Contributor

@knz knz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm:

Reviewed 2 of 2 files at r2, all commit messages.
Reviewable status: :shipit: complete! 1 of 0 LGTMs obtained (waiting on @jeffswenson, @smg260, and @srosenberg)

@healthy-pod
Copy link
Contributor Author

bors r=knz

@craig
Copy link
Contributor

craig bot commented Aug 21, 2023

Build failed (retrying...):

@craig
Copy link
Contributor

craig bot commented Aug 21, 2023

Build failed (retrying...):

@craig
Copy link
Contributor

craig bot commented Aug 21, 2023

Build succeeded:

@craig craig bot merged commit 8004dcd into cockroachdb:master Aug 21, 2023
@knz knz mentioned this pull request Sep 20, 2023
renatolabs pushed a commit to renatolabs/cockroach that referenced this pull request Jul 22, 2024
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
renatolabs pushed a commit to renatolabs/cockroach that referenced this pull request Jul 30, 2024
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
craig bot pushed a commit that referenced this pull request Jul 30, 2024
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>
blathers-crl bot pushed a commit that referenced this pull request Jul 30, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-multitenancy Related to multi-tenancy backport-23.1.x PAST MAINTENANCE SUPPORT: 23.1 patch releases via ER request only

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants