This is a followup to #73857, to be interpreted in the context of #77935.
We would like the ability to run ALTER TENANT x SET CLUSTER SETTING version = XXX
and have this statement trigger the SQL migrations for the target tenant.
However doing so is made more complex by the fact that the SQL server which is running ALTER TENANT SET CLUSTER SETTING does not have visibility over the target tenant keyspace directly and so cannot trigger the SQL migrations itself.
Instead, we should probably design some kind of RPC by which the target tenant "learns" of the version change.
Workaround
Until this issue is fixed, a DBA who wants to upgrade the logical version of a tenant should log into that tenant and run the SET CLUSTER SETTING statmeent in the context of that tenant.
Jira issue: CRDB-13742
Epic CRDB-14080
This is a followup to #73857, to be interpreted in the context of #77935.
We would like the ability to run
ALTER TENANT x SET CLUSTER SETTING version = XXXand have this statement trigger the SQL migrations for the target tenant.
However doing so is made more complex by the fact that the SQL server which is running ALTER TENANT SET CLUSTER SETTING does not have visibility over the target tenant keyspace directly and so cannot trigger the SQL migrations itself.
Instead, we should probably design some kind of RPC by which the target tenant "learns" of the version change.
Workaround
Until this issue is fixed, a DBA who wants to upgrade the logical version of a tenant should log into that tenant and run the SET CLUSTER SETTING statmeent in the context of that tenant.
Jira issue: CRDB-13742
Epic CRDB-14080