Skip to content
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

cli/start: check if the special version initialization for secondary tenants can go away #90831

Closed
knz opened this issue Oct 28, 2022 · 8 comments
Assignees
Labels
A-cluster-upgrades A-multitenancy Related to multi-tenancy C-investigation Further steps needed to qualify. C-label will change. T-multitenant Issues owned by the multi-tenant virtual team

Comments

@knz
Copy link
Contributor

knz commented Oct 28, 2022

Describe the problem

In the server startup for secondary tenant, we see the following special-purpose code:

    // This value is injected in order to have something populated during startup.
    // In the initial 20.2 release of multi-tenant clusters, no version state was
    // ever populated in the version cluster setting. A value is populated during
    // the activation of 21.1. See the documentation attached to the TenantCluster
    // in upgrade/upgradecluster for more details on the tenant upgrade flow.
    // Note that a the value of 21.1 is populated when a tenant cluster is created
    // during 21.1 in crdb_internal.create_tenant.
    //
    // Note that the tenant will read the value in the system.settings table
    // before accepting SQL connections.
    //
    // TODO(knz): Check if this special initialization can be removed.
    // See:
    stserverCfg.BaseConfig.Settings
    return clusterversion.Initialize(
      ctx, st.Version.BinaryMinSupportedVersion(), &st.SV,
    )

Is this initialization still relevant? Can we remove it?

cc @dt @ajstorm for advice.

Jira issue: CRDB-20962

Epic CRDB-10829

@knz knz added C-investigation Further steps needed to qualify. C-label will change. A-multitenancy Related to multi-tenancy A-cluster-upgrades labels Oct 28, 2022
@ajstorm
Copy link
Collaborator

ajstorm commented Oct 28, 2022

Yeah, I noticed this too in my work this week and was planning on deleting it. Feel free to do so yourself if you get to it first, unless @dt disagrees.

@knz
Copy link
Contributor Author

knz commented Oct 28, 2022

So it's safe to delete?

@ajstorm
Copy link
Collaborator

ajstorm commented Oct 28, 2022

That's my opinion, unless I'm misunderstanding something. It seems like ever since 21.1 we were populating this value correctly here:

cockroach/pkg/sql/tenant.go

Lines 267 to 278 in 8cdaa31

// Populate the version setting for the tenant. This will allow the tenant
// to know what migrations need to be run in the future. The choice to use
// the active cluster version here is intentional; it allows tenants
// created during the mixed-version state in the host cluster to avoid
// using code which may be too new. The expectation is that the tenant
// clusters will be updated to a version only after the system tenant has
// been upgraded.
v := p.EvalContext().Settings.Version.ActiveVersion(ctx)
tenantSettingKV, err := generateTenantClusterSettingKV(codec, v)
if err != nil {
return err
}
).

I think this means that we should also be able to remove this code:

// The tenant cluster in 20.2 did not ever initialize this value and
// utilized this hard-coded value instead. In 21.1, the builtin
// which creates tenants sets up the cluster version state. It also
// is set when the version is upgraded.
tenantDefaultVersion := clusterversion.ClusterVersion{
Version: roachpb.Version{Major: 20, Minor: 2},
}

@knz
Copy link
Contributor Author

knz commented Oct 31, 2022

ok i'll remove it in #90176

@knz
Copy link
Contributor Author

knz commented Oct 31, 2022

Sadly, that bit is not optional. Without it, SQL server initialization fails:

F221031 13:42:42.810253 346 clusterversion/setting.go:124  [nsql2] 40  version not initialized

triggered by sql.(*TemporaryObjectCleaner).Start.

This tells me that we need some value in the in-memory setting before the actual first value is fetched from KV.

@craig craig bot closed this as completed in b7b658f Oct 31, 2022
@knz
Copy link
Contributor Author

knz commented Oct 31, 2022

This was closed by mistake. Still current.

@knz knz reopened this Oct 31, 2022
@knz
Copy link
Contributor Author

knz commented Jan 19, 2023

cc @healthy-pod for info

@exalate-issue-sync exalate-issue-sync bot added the T-multitenant Issues owned by the multi-tenant virtual team label Jan 19, 2023
@knz
Copy link
Contributor Author

knz commented Apr 5, 2023

ok now I understand why this must be there. No need for this issue any more.

@knz knz closed this as completed Apr 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-cluster-upgrades A-multitenancy Related to multi-tenancy C-investigation Further steps needed to qualify. C-label will change. T-multitenant Issues owned by the multi-tenant virtual team
Projects
None yet
Development

No branches or pull requests

3 participants