additionalVolumeClaimTemplates: is "fixed at creation" a permanent constraint, or could additions be allowed?

Aperta
  • Qualcosa non va?
#293 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
clickhouse, go, kubernetes
Ambito
databases, infrastructure

Direzione di ricerca

Inizia da internal/webhook/v1alpha1/common.go intorno alla riga 125 e da internal/controller/resourcemanager.go intorno alla riga 269 per tracciare la validazione e la riconciliazione di additionalVolumeClaimTemplates. Esamina quindi come l’operatore esegue il provisioning e fa riferimento ai PVC di StatefulSet per i cluster esistenti. Il lavoro è completo quando le aggiunte possono essere applicate a un cluster esistente contenente dati senza essere rifiutate o scartate, preservando al contempo il comportamento previsto di PVC e StatefulSet.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

feature
Company or project name

No response

Use case

Two situations, both on clusters that already exist and hold data:

  1. Growing capacity. Adding a disk is the natural way to extend a cluster that's filling up. Today that's only available to clusters whose authors anticipated it at creation time; everyone else has to recreate.

  2. Per-tenant storage isolation. We need a dedicated volume encrypted with a specific customer's managed KMS key, holding exactly one tenant's table and nothing else. This requirement arrives well after the cluster is built — it comes from a contract, not from capacity planning — and the key doesn't exist until the customer creates it. Recreating a multi-terabyte production cluster to attach it isn't practical.

Describe the solution you'd like

Allow additions to additionalVolumeClaimTemplates after cluster creation.

Note the restriction is currently enforced in two places, so the webhook alone isn't the whole change:

// internal/webhook/v1alpha1/common.go:125 — rejects the spec change
if len(oldTemplates) != len(newTemplates) {
    return errors.New("additionalVolumeClaimTemplates cannot be added or removed after cluster creation")
}

// internal/controller/resourcemanager.go:269 — discards it on reconcile
statefulSet.Spec.VolumeClaimTemplates = input.Existing.STS.Spec.VolumeClaimTemplates

One mechanism that avoids the immutability problem entirely: volumeClaimTemplates are only used for provisioning, and a StatefulSet uses a PVC that already exists under the name it expects. So the operator can create the PVC directly per replica and reference it from the pod template — which is mutable — leaving volumeClaimTemplates untouched.

Describe alternatives you've considered
  • Declare spare disks at creation time. Doesn't fit either use case: you'd pay for idle volumes indefinitely, and you cannot pre-declare a StorageClass for a customer KMS key that doesn't exist yet.
  • Declare the disk via settings.extraConfig without a claim. This appears to work and silently doesn't. With no PVC, the disk's path is just a directory on the main data volume — ClickHouse registers the disk, system.disks shows it, a storage policy over it works, and parts report landing on it. For an encryption-isolation requirement that's the worst failure mode available: every signal says success while the data sits on the wrong volume under the wrong key. The tell is total_space matching the main volume.
  • Recreate the ClickHouseCluster CR against the existing PVCs. Plausible, but it means deliberate downtime on a production cluster and depends on adoption behaving exactly as hoped.
  • Recreate the StatefulSet with orphaned PVCs. Also viable and possibly what you'd prefer — more invasive, but keeps volumeClaimTemplates authoritative.
  • A downstream patch. What we do today. We'd rather not carry it, which is why we're asking here.
Additional context

No response

Lingua principale
Go
Stelle
313
Fork
48
Merge medio
1g 15h
PR unite (30g)
21

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ClickHouse/clickhouse-operator

Tutte le issue di ClickHouse/clickhouse-operator

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.