Allow overriding the vtbackup data volume per tablet pool (#661)

[mcrauwel]

Summary

Fixes #661.

vtbackup Pods — both the initial --initial_backup taken at shard creation and any periodic/scheduled backups — inherit their spec from the tablet pool, including dataVolumeClaimTemplate. That forces a PVC (and underlying disk) to be allocated per shard just to bootstrap an empty backup. In large clusters this is wasteful and sometimes unschedulable, as called out in the issue.

This adds an optional vtbackup block on VitessShardTabletPool with a dataVolumeClaimTemplate override, decoupling the vtbackup Pod's storage from the tablets':

tabletPools:
- cell: cell1
  type: replica
  replicas: 3
  dataVolumeClaimTemplate:        # tablets still get their normal PVC
    accessModes: [ReadWriteOnce]
    resources: {requests: {storage: 100Gi}}
  vtbackup:
    # omit dataVolumeClaimTemplate => vtbackup Pods run with NO PVC (emptyDir)
    # or set one to use a smaller disk / different storageClass:
    dataVolumeClaimTemplate:
      storageClassName: cheap-disk
      accessModes: [ReadWriteOnce]
      resources: {requests: {storage: 10Gi}}

Semantics

vtbackup block	vtbackup Pod data volume
omitted	inherits the pool's dataVolumeClaimTemplate (unchanged behavior)
present, dataVolumeClaimTemplate omitted	no PVC — ephemeral emptyDir scratch space
dataVolumeClaimTemplate set	uses that template (smaller disk, different storageClass, etc.)

Both code paths funnel through MakeVtbackupSpec, so the override applies consistently to initial and scheduled backups. Tablet Pods are unaffected. Default behavior is fully backwards compatible.

Scope note

This first pass intentionally covers only the data volume — the concrete pain in the issue. The broader "override the whole vtbackup pod spec" idea (and the comment's request to label the vitessbackupstorage subcontroller) can build on this vtbackup block in follow-ups.

Tests

• Unit (reconcile_backup_job_test.go): all three states of the data-volume override.
• Integration: an empty vtbackup: {} override on the first pool yields a vtbackup-init Pod with no PVC-backed volume, while the tablet Pods keep their PVCs. (Verified locally on arm64 envtest.)
• Regenerated CRDs / deepcopy / API docs.

🤖 Generated with Claude Code

[frouioui]

We should fail with an error here instead. Otherwise the job we create won't have any corresponding PVC and will fail.

[mattlord]

I looked at this more closely and I don't think the Job references a missing PVC. NewBackupPod derives both the volume and mounts from DataVolumePVCSpec; when it is nil, it omits the PVC volume and mounts /vt/vtdataroot from the existing vt-root emptyDir. That no-PVC Job is the behavior requested by #661. I've restored this path locally and strengthened the test to assert that the Job has no PVC-backed volume and that no PVC object is created.

[mattlord]

Addressed in c2e444c.

[frouioui]

vts.Spec.Vtbackup.DataVolumeClaimTemplate is an optional field, we should only override the dataVolumeClaimTemplate if we the user has defined something in the CR.

[mattlord]

I think the nil inner field is intentional here. The two pointers provide the three states this API needs: no vtbackup block inherits the pool PVC; an empty block selects emptyDir; a non-nil dataVolumeClaimTemplate selects a custom PVC. Checking both pointers collapses the first two states and leaves no way to request the no-PVC behavior from #661. I've restored the three-state handling and its tests in c2e444c.

[frouioui]

Since we are modifying the CRD, we need to re-generate the operator yaml files, the test files, and port the related changes to the vitess repository, like so: #629 (comment)

[mattlord]

We can do one vitessio/vitess PR once this and #797 are both merged.