Describe the bug
With clickhouseKeeper.enabled: true (the default) a ClickHouse application whose name is longer than 15 characters never gets a Keeper: the operator cannot create the Keeper StatefulSet because one of its volume names exceeds 63 characters. The ClickHouseKeeperInstallation still reports status: Completed, so the only visible signal is the Keeper WorkloadMonitor staying at operational: false.
packages/apps/clickhouse/templates/chkeeper.yaml names the CHK {{ .Release.Name }}-keeper, and Release.Name is already clickhouse-<name>. clickhouse-operator then derives the config volume name chk-<chk-name>-deploy-confd-<cluster>-<shard>-<replica>. With the fixed parts (chk-, clickhouse-, -keeper, -deploy-confd-, cluster1, -0-0) that leaves 15 characters for the application name before the Kubernetes limit is hit.
Environment
- Cozystack v1.6.1 (platform 54), clickhouse-operator 0.25.2;
chkeeper.yaml on main is unchanged
- on-prem, Talos
To Reproduce
- Create a ClickHouse application named
clickhouse-backup (17 characters) with default values.
- Wait for the HelmRelease to report
InstallSucceeded.
kubectl get chk clickhouse-clickhouse-backup-keeper shows Completed; kubectl get sts,pods -l app=clickhouse-clickhouse-backup-keeper returns nothing.
Expected behaviour
Either the Keeper comes up regardless of a reasonable application name, or the name is rejected up front with a clear message.
Actual behaviour
No Keeper StatefulSet, no Keeper pod, the keeper-<chk> Service has no endpoints. The ClickHouse pod itself runs, so plain tables work while anything that needs Keeper (ReplicatedMergeTree, ON CLUSTER) does not. The failure repeats on every reconcile and is only logged by the operator.
Logs
statefulset-reconciler.go:364] doCreateStatefulSet():Host:0-0[0/0]:tenant-rup6ev1r6z/clickhouse-clickhouse-backup-keeper:StatefulSet create failed. err: StatefulSet.apps "chk-clickhouse-clickhouse-backup-keeper-cluster1-0-0" is invalid: [spec.template.spec.volumes[3].name: Invalid value: "chk-clickhouse-clickhouse-backup-keeper-deploy-confd-cluster1-0-0": must be no more than 63 characters, spec.template.spec.containers[0].volumeMounts[2].name: Not found: "chk-clickhouse-clickhouse-backup-keeper-deploy-confd-cluster1-0-0"]
statefulset-reconciler.go:346] Host:0-0[0/0]:tenant-rup6ev1r6z/clickhouse-clickhouse-backup-keeper:Got recreate action. Ignore and continue for now
Possible directions: a shorter generated CHK name (the clickhouse- prefix is repeated twice today) or a shorter cluster name than cluster1, plus a maxLength on the application name for this kind so the dashboard rejects it instead of reporting a green install. Happy to send a patch once the maintainers pick the direction.
Describe the bug
With
clickhouseKeeper.enabled: true(the default) a ClickHouse application whose name is longer than 15 characters never gets a Keeper: the operator cannot create the Keeper StatefulSet because one of its volume names exceeds 63 characters. TheClickHouseKeeperInstallationstill reportsstatus: Completed, so the only visible signal is the KeeperWorkloadMonitorstaying atoperational: false.packages/apps/clickhouse/templates/chkeeper.yamlnames the CHK{{ .Release.Name }}-keeper, andRelease.Nameis alreadyclickhouse-<name>. clickhouse-operator then derives the config volume namechk-<chk-name>-deploy-confd-<cluster>-<shard>-<replica>. With the fixed parts (chk-,clickhouse-,-keeper,-deploy-confd-,cluster1,-0-0) that leaves 15 characters for the application name before the Kubernetes limit is hit.Environment
chkeeper.yamlonmainis unchangedTo Reproduce
clickhouse-backup(17 characters) with default values.InstallSucceeded.kubectl get chk clickhouse-clickhouse-backup-keepershowsCompleted;kubectl get sts,pods -l app=clickhouse-clickhouse-backup-keeperreturns nothing.Expected behaviour
Either the Keeper comes up regardless of a reasonable application name, or the name is rejected up front with a clear message.
Actual behaviour
No Keeper StatefulSet, no Keeper pod, the
keeper-<chk>Service has no endpoints. The ClickHouse pod itself runs, so plain tables work while anything that needs Keeper (ReplicatedMergeTree, ON CLUSTER) does not. The failure repeats on every reconcile and is only logged by the operator.Logs
Possible directions: a shorter generated CHK name (the
clickhouse-prefix is repeated twice today) or a shorter cluster name thancluster1, plus amaxLengthon the application name for this kind so the dashboard rejects it instead of reporting a green install. Happy to send a patch once the maintainers pick the direction.