sql,*: align settings defaults for UA

[dt]

Several features are controlled for such that they can behave differently secondary tenants, with settings or knobs that can choose between restricting or altering the behavior to be more aligned with a multi-tenant hosted service like CC Serverless or a dedicated cluster, either in the system tenant today or in UA app tenants.

Previously, when multi-tenant hosted deployments were the only deployments in which secondary tenants were used, it made sense for such controls to assume it as their default, e.g. default to restricting a behavior that is running int a secondary tenant to run as if it is in a hosted MT service. However, as we move to unified architecture and running all workloads in secondary tenants, even in dedicated and self-hosted clusters, these defaults no longer make as much sense: the out-of-the-box default experience for an application using a UA cluster should be as close to one using a pre-UA cluster, and if the behavior needs to behave differently in a MT hosted/serverless environment, that environment can be responsible for reconfiguring or overriding it accordingly.

To that end, the changes in this CL flip the defaults on several controls of behaviors in secondary tenants, to align the out-of-box experience of a UA cluster with that of a non-UA cluster. When our hosted MT service deploys the version in which these default changes take effect, it will need to add explicit configuration overrides accordingly.

See individual commits for details and release notes.

Epic: none.

[cockroach-teamcity]

This change is 

[stevendanna]

Overall, I think this is the right direction to take things. We'll want to make a list of overrides that CC should set.

The last commit regarding disable_drop_virtual_cluster gives me a little pause. I agree that DROP TENANT isn't different from DROP DATABASE in terms of the danger it represents. Our main concern at the time is that DROP TENANT is something we might instruct the user to run on a PCR destination cluster that would be pretty disastrous to run on the source cluster (combined with the concern that sql_safe_updates doesn't apply to someone who is driving their cluster through something that doesn't set that session var). But, you were very clever putting this last in the series of commits as that empty initial cluster config makes it much more tempting.

[stevendanna]

We might consider backporting this change to 23.2.

[dt]

I would feel better if we did, but we need to identify/write up a bug it is fixing first to do so.

[dt]

DROP TENANT is something we might instruct the user to run on a PCR destination cluster that would be pretty disastrous to run on the source cluster

Sure, and DROP DATABASE is something that you might run in your staging or development cluster but which would be disastrous if run in production, right?

[dt]

We'll want to make a list of overrides that CC should set.

I have this sitting my editor to copy to a Jira ticket when this merges:

After all serverless hosts are on 23.2, but before they go to 24.1, they and newly created clusters will need to:

// Flip the override for all tenants so they do not send manual splits/scatters.
"ALTER VIRTUAL CLUSTER ALL SET CLUSTER SETTING sql.virtual_cluster.feature_access.manual_range_scatter.enabled = false",
"ALTER VIRTUAL CLUSTER ALL SET CLUSTER SETTING sql.virtual_cluster.feature_access.manual_range_split.enabled = false",

// Enable trace redaction
"SET CLUSTER SETTING trace.redact_at_virtual_cluster_boundary.enabled = true",

// Disable unrestricted zone config changes in secondary tenants 
"SET CLUSTER SETTING sql.virtual_cluster.feature_access.zone_configs.enabled = false",
"SET CLUSTER SETTING sql.virtual_cluster.feature_access.zone_configs_unrestricted.enabled = false",

// Disable multi-region abstractions in secondary tenants (on non-MR hosts)
"SET CLUSTER SETTING sql.virtual_cluster.feature_access.multiregion.enabled = false",

[dt]

TFTR!

bors r+

[jaylim-crl]

We'll want to make a list of overrides that CC should set.

I have this sitting my editor to copy to a Jira ticket when this merges:

After all serverless hosts are on 23.2, but before they go to 24.1, they and newly created clusters will need to:

// Flip the override for all tenants so they do not send manual splits/scatters.
"ALTER VIRTUAL CLUSTER ALL SET CLUSTER SETTING sql.virtual_cluster.feature_access.manual_range_scatter.enabled = false",
"ALTER VIRTUAL CLUSTER ALL SET CLUSTER SETTING sql.virtual_cluster.feature_access.manual_range_split.enabled = false",

// Enable trace redaction
"SET CLUSTER SETTING trace.redact_at_virtual_cluster_boundary.enabled = true",

// Disable unrestricted zone config changes in secondary tenants 
"SET CLUSTER SETTING sql.virtual_cluster.feature_access.zone_configs.enabled = false",
"SET CLUSTER SETTING sql.virtual_cluster.feature_access.zone_configs_unrestricted.enabled = false",

// Disable multi-region abstractions in secondary tenants (on non-MR hosts)
"SET CLUSTER SETTING sql.virtual_cluster.feature_access.multiregion.enabled = false",

Could we also set these settings now (prior to 23.2 upgrade), if we used the old names?

[dt]

Could we also set these settings now (prior to 23.2 upgrade), if we used the old names?

Yep, any of them that exist now, if we set them using their current (23.1) names, that'll still be the storage key for them in 23.2 and 24.1, so no need to wait for the aliases.

[craig]

Build succeeded:

• Bazel Essential CI (Cockroach)