Allow custom database name override.

deploy/crds/planetscale_v2_vitesscluster_crd.yaml

@@ -987,6 +987,20 @@ spec:
                 +patchStrategy=merge'
               items:
                 properties:
+                  databaseName:
+                    description: 'DatabaseName is the name to use for the underlying,
+                      physical MySQL database created to hold data for the keyspace.  This
+                      name is mostly hidden from Vitess clients, which should see
+                      and use only the keyspace name as a logical database. However,
+                      you may want to set this to control the name used by clients
+                      that bypass Vitess and connect directly to the underlying MySQL,
+                      such as certain DBA tools.  The default, when the field is either
+                      left unset or set to empty string, is to add a "vt_" prefix
+                      to the keyspace name since that has historically been the default
+                      in Vitess itself. However, it''s often preferable to set this
+                      to be the same as the keyspace name to reduce confusion.  Default:
+                      Add a "vt_" prefix to the keyspace name.'
+                    type: string
                   name:
                     description: 'Name is the keyspace name as it should be provided
                       to Vitess. Note that this is different from the VitessKeyspace

deploy/crds/planetscale_v2_vitesskeyspace_crd.yaml

@@ -239,6 +239,19 @@ spec:
                     type: object
                 type: object
               type: array
+            databaseName:
+              description: 'DatabaseName is the name to use for the underlying, physical
+                MySQL database created to hold data for the keyspace.  This name is
+                mostly hidden from Vitess clients, which should see and use only the
+                keyspace name as a logical database. However, you may want to set
+                this to control the name used by clients that bypass Vitess and connect
+                directly to the underlying MySQL, such as certain DBA tools.  The
+                default, when the field is either left unset or set to empty string,
+                is to add a "vt_" prefix to the keyspace name since that has historically
+                been the default in Vitess itself. However, it''s often preferable
+                to set this to be the same as the keyspace name to reduce confusion.  Default:
+                Add a "vt_" prefix to the keyspace name.'
+              type: string
             extraVitessFlags:
               additionalProperties:
                 type: string

deploy/crds/planetscale_v2_vitessshard_crd.yaml

@@ -276,6 +276,11 @@ spec:
               required:
               - key
               type: object
+            databaseName:
+              description: DatabaseName is the name to use for the underlying MySQL
+                database. It is inherited from the parent keyspace, so it can only
+                be configured at the keyspace level.
+              type: string
             extraVitessFlags:
               additionalProperties:
                 type: string
@@ -397,7 +402,7 @@ spec:
                   type: string
               type: object
             name:
-              description: Name is the shard name as its known to Vitess.
+              description: Name is the shard name as it's known to Vitess.
               type: string
             replication:
               description: Replication configures Vitess replication settings for

docs/api/index.html

@@ -4760,6 +4760,27 @@ <h3 id="planetscale.com/v2.VitessKeyspaceTemplate">VitessKeyspaceTemplate
 </tr>
 <tr>
 <td>
+<code>databaseName</code></br>
+<em>
+string
+</em>
+</td>
+<td>
+<p>DatabaseName is the name to use for the underlying, physical MySQL
+database created to hold data for the keyspace.</p>
+<p>This name is mostly hidden from Vitess clients, which should see and use
+only the keyspace name as a logical database. However, you may want to
+set this to control the name used by clients that bypass Vitess and
+connect directly to the underlying MySQL, such as certain DBA tools.</p>
+<p>The default, when the field is either left unset or set to empty string,
+is to add a &ldquo;vt_&rdquo; prefix to the keyspace name since that has historically
+been the default in Vitess itself. However, it&rsquo;s often preferable to set
+this to be the same as the keyspace name to reduce confusion.</p>
+<p>Default: Add a &ldquo;vt_&rdquo; prefix to the keyspace name.</p>
+</td>
+</tr>
+<tr>
+<td>
 <code>partitionings</code></br>
 <em>
 <a href="#planetscale.com/v2.VitessKeyspacePartitioning">
@@ -5030,7 +5051,20 @@ <h3 id="planetscale.com/v2.VitessShard">VitessShard
 </em>
 </td>
 <td>
-<p>Name is the shard name as its known to Vitess.</p>
+<p>Name is the shard name as it&rsquo;s known to Vitess.</p>
+</td>
+</tr>
+<tr>
+<td>
+<code>databaseName</code></br>
+<em>
+string
+</em>
+</td>
+<td>
+<p>DatabaseName is the name to use for the underlying MySQL database.
+It is inherited from the parent keyspace, so it can only be configured at
+the keyspace level.</p>
 </td>
 </tr>
 <tr>
@@ -5283,7 +5317,20 @@ <h3 id="planetscale.com/v2.VitessShardSpec">VitessShardSpec
 </em>
 </td>
 <td>
-<p>Name is the shard name as its known to Vitess.</p>
+<p>Name is the shard name as it&rsquo;s known to Vitess.</p>
+</td>
+</tr>
+<tr>
+<td>
+<code>databaseName</code></br>
+<em>
+string
+</em>
+</td>
+<td>
+<p>DatabaseName is the name to use for the underlying MySQL database.
+It is inherited from the parent keyspace, so it can only be configured at
+the keyspace level.</p>
 </td>
 </tr>
 <tr>

pkg/apis/planetscale/v2/vitesskeyspace_types.go

@@ -96,6 +96,22 @@ type VitessKeyspaceTemplate struct {
 	// +kubebuilder:validation:Pattern=^[a-z0-9]([a-z0-9]*[a-z0-9])?$
 	Name string `json:"name"`
 
+	// DatabaseName is the name to use for the underlying, physical MySQL
+	// database created to hold data for the keyspace.
+	//
+	// This name is mostly hidden from Vitess clients, which should see and use
+	// only the keyspace name as a logical database. However, you may want to
+	// set this to control the name used by clients that bypass Vitess and
+	// connect directly to the underlying MySQL, such as certain DBA tools.
+	//
+	// The default, when the field is either left unset or set to empty string,
+	// is to add a "vt_" prefix to the keyspace name since that has historically
+	// been the default in Vitess itself. However, it's often preferable to set
+	// this to be the same as the keyspace name to reduce confusion.
+	//
+	// Default: Add a "vt_" prefix to the keyspace name.
+	DatabaseName string `json:"databaseName,omitempty"`
+
 	// Partitionings specify how to divide the keyspace up into shards by
 	// defining the range of keyspace IDs that each shard contains.
 	// For example, you might divide the keyspace into N equal-sized key ranges.

pkg/apis/planetscale/v2/vitessshard_types.go

@@ -53,9 +53,14 @@ type VitessShardSpec struct {
 	// The rest of the fields below are filled in by the parent controller.
 	VitessShardTemplate `json:",inline"`
 
-	// Name is the shard name as its known to Vitess.
+	// Name is the shard name as it's known to Vitess.
 	Name string `json:"name"`
 
+	// DatabaseName is the name to use for the underlying MySQL database.
+	// It is inherited from the parent keyspace, so it can only be configured at
+	// the keyspace level.
+	DatabaseName string `json:"databaseName,omitempty"`
+
 	// ZoneMap is a map from Vitess cell name to zone (failure domain) name
 	// for all cells defined in the VitessCluster.
 	ZoneMap map[string]string `json:"zoneMap"`

pkg/apis/planetscale/v2/zz_generated.openapi.go

@@ -1010,6 +1010,13 @@ func schema_pkg_apis_planetscale_v2_VitessKeyspaceSpec(ref common.ReferenceCallb
 							Format:      "",
 						},
 					},
+					"databaseName": {
+						SchemaProps: spec.SchemaProps{
+							Description: "DatabaseName is the name to use for the underlying, physical MySQL database created to hold data for the keyspace.\n\nThis name is mostly hidden from Vitess clients, which should see and use only the keyspace name as a logical database. However, you may want to set this to control the name used by clients that bypass Vitess and connect directly to the underlying MySQL, such as certain DBA tools.\n\nThe default, when the field is either left unset or set to empty string, is to add a \"vt_\" prefix to the keyspace name since that has historically been the default in Vitess itself. However, it's often preferable to set this to be the same as the keyspace name to reduce confusion.\n\nDefault: Add a \"vt_\" prefix to the keyspace name.",
+							Type:        []string{"string"},
+							Format:      "",
+						},
+					},
 					"partitionings": {
 						SchemaProps: spec.SchemaProps{
 							Description: "Partitionings specify how to divide the keyspace up into shards by defining the range of keyspace IDs that each shard contains. For example, you might divide the keyspace into N equal-sized key ranges.\n\nNote that this is distinct from defining how each row maps to a keyspace ID, which is done in the VSchema. Partitioning is purely an operational concern (scaling the infrastructure), while VSchema is an application-level concern (modeling relationships between data). This separation of concerns allows resharding to occur generically at the infrastructure level without any knowledge of the data model.\n\nEach partitioning must define a set of shards that fully covers the space of all possible keyspace IDs; there can be no gaps between ranges. There's usually only one partitioning present at a time, but during resharding, it's necessary to launch the destination shards alongside the source shards. When the resharding is complete, the old partitioning can be removed, which will turn down (undeploy) any unneeded shards.\n\nIf only some shards are being split or joined during resharding, the shards that aren't changing must be specified in both partitionings, although the common shards will be shared (only deployed once). If the per-shard configuration differs, the configuration in the latter partitioning (in the order listed in this field) will be used. For this reason, it's recommended to add new partitionings at the end, and only remove partitionings from the beginning.\n\nThis field is required. An unsharded keyspace may be specified as a partitioning into 1 part.",
@@ -1272,7 +1279,14 @@ func schema_pkg_apis_planetscale_v2_VitessShardSpec(ref common.ReferenceCallback
 					},
 					"name": {
 						SchemaProps: spec.SchemaProps{
-							Description: "Name is the shard name as its known to Vitess.",
+							Description: "Name is the shard name as it's known to Vitess.",
+							Type:        []string{"string"},
+							Format:      "",
+						},
+					},
+					"databaseName": {
+						SchemaProps: spec.SchemaProps{
+							Description: "DatabaseName is the name to use for the underlying MySQL database. It is inherited from the parent keyspace, so it can only be configured at the keyspace level.",
 							Type:        []string{"string"},
 							Format:      "",
 						},

pkg/controller/vitesskeyspace/reconcile_shards.go

@@ -162,6 +162,7 @@ func newVitessShard(key client.ObjectKey, vtk *planetscalev2.VitessKeyspace, par
 			Images:                 vtk.Spec.Images,
 			ImagePullPolicies:      vtk.Spec.ImagePullPolicies,
 			Name:                   shard.KeyRange.String(),
+			DatabaseName:           vtk.Spec.DatabaseName,
 			KeyRange:               shard.KeyRange,
 			ZoneMap:                vtk.Spec.ZoneMap,
 			BackupLocations:        vtk.Spec.BackupLocations,

pkg/controller/vitessshard/reconcile_backup_job.go

@@ -236,6 +236,7 @@ func vtbackupSpec(key client.ObjectKey, vts *planetscalev2.VitessShard, parentLa
 			DataVolumePVCName:        key.Name,
 			DataVolumePVCSpec:        pool.DataVolumeClaimTemplate,
 			KeyspaceName:             keyspaceName,
+			DatabaseName:             vts.Spec.DatabaseName,
 			DatabaseInitScriptSecret: vts.Spec.DatabaseInitScriptSecret,
 			BackupLocation:           backupLocation,
 			BackupEngine:             vts.Spec.BackupEngine,

pkg/controller/vitessshard/reconcile_tablets.go

@@ -316,6 +316,7 @@ func vttabletSpecs(vts *planetscalev2.VitessShard, parentLabels map[string]strin
 				Type:                     pool.Type,
 				DataVolumePVCSpec:        pool.DataVolumeClaimTemplate,
 				KeyspaceName:             keyspaceName,
+				DatabaseName:             vts.Spec.DatabaseName,
 				DatabaseInitScriptSecret: vts.Spec.DatabaseInitScriptSecret,
 				EnableSemiSync:           vts.Spec.Replication.EnforceSemiSync,
 				Annotations:              annotations,

pkg/operator/vttablet/spec.go

@@ -38,6 +38,7 @@ type Spec struct {
 	Index                    int32
 	KeyRange                 planetscalev2.VitessKeyRange
 	KeyspaceName             string
+	DatabaseName             string
 	Vttablet                 *planetscalev2.VttabletSpec
 	Mysqld                   *planetscalev2.MysqldSpec
 	ExternalDatastore        *planetscalev2.ExternalDatastore
@@ -60,6 +61,9 @@ type Spec struct {
 
 // localDatabaseName returns the MySQL database name for a tablet Spec in the case of locally managed MySQL.
 func (spec *Spec) localDatabaseName() string {
+	if spec.DatabaseName != "" {
+		return spec.DatabaseName
+	}
 	return "vt_" + spec.KeyspaceName
 }