fix(clickstack-operators): bump clickhouse-operator-helm dep to >=0.0.5

[ZeynelKoca]

Problem

The clickstack-operators chart at v1.0.0 declares its clickhouse-operator-helm dependency as ~0.0.2. In Helm's Masterminds semver implementation, the tilde range for pre-1.0 patch-level versions is interpreted narrowly as >=0.0.2 <0.0.3 — so this dep resolves only to v0.0.2 of the operator chart, even though newer 0.0.x releases (v0.0.3, v0.0.4, v0.0.5) exist.

Consumers of clickstack-operators v1.0.0 are effectively pinned to operator v0.0.2 and miss every fix since then. In particular, v0.0.5 ships:

• New CRD schema field spec.podDisruptionBudget on both ClickHouseCluster and KeeperCluster (lets users override the auto-generated PDB).
• Smart default for ClickHouseCluster with replicas <= 1: maxUnavailable=1 (instead of minAvailable=1) so single-replica clusters do not deadlock on voluntary disruption (e.g. node drains, upgrades).
• RBAC additions (notably the Jobs informer the v0.0.5 controller manager requires).

We hit this in production: a single-replica deployment of ClickStack on AKS got stuck on a node-pool VM resize because the v0.0.2 operator generated PDBs that no eviction could satisfy (minAvailable=1 on a 1-replica ClickHouse, maxUnavailable=0 on a 1-replica Keeper). Bumping the wrapper chart's operator image alone is not enough — the v0.0.5 binary crashloops against v0.0.2's RBAC/CRDs.

Fix

Widen the dependency constraint so the chart pulls v0.0.5 (and stays compatible with future 0.0.x releases):

# charts/clickstack-operators/Chart.yaml
- name: clickhouse-operator-helm
  version: ">=0.0.5, <0.1.0"   # was: "~0.0.2"

This pulls operator v0.0.5 + its matching CRDs + matching RBAC together, as one consistent set.

Verification

$ helm dependency build charts/clickstack-operators
Pulled: ghcr.io/clickhouse/clickhouse-operator-helm:0.0.5

$ helm template clickstack-operators charts/clickstack-operators | grep -c "^kind:"
29

Resolves cleanly, no template errors, all expected resources render.

Changeset

Added .changeset/bump-clickhouse-operator-helm.md (minor bump) describing the user-visible change for the next release.

Notes for adopters

Existing installations have CRDs with helm.sh/resource-policy: keep (from the original install), which prevents Helm from updating them on upgrade. After this change merges and a new chart release is published, adopters upgrading from v1.0.0 will need a one-time kubectl apply -f of the new CRDs (or remove the keep annotation) to pick up the new schema. This is unrelated to this PR but worth mentioning in the release notes.

[changeset-bot]

🦋 Changeset detected

Latest commit: bb4050b

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
helm-charts	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[ZeynelKoca]

@dhable Any indication on when this can be merged + released? Running into production upgrade issues now, which we had to find a temporary solution for.

[ZeynelKoca]

Relevant PR for single-replica upgrade issues: ClickHouse/clickhouse-operator#208

[ZeynelKoca]

@dhable Gentle bump. Is this project still maintained? Anything we can do to help gain momentum here? Feels like this repo is losing momentum against the other clickstack repos which would be a shame

[github-actions]

Deep Review

Scope: charts/clickstack-operators/Chart.yaml (dependency constraint ~0.0.2 → >=0.0.5, <0.1.0) + new .changeset/bump-clickhouse-operator-helm.md, against base 375aa06.
Intent: Widen the clickhouse-operator-helm dependency so consumers pull operator v0.0.5 (new CRD field, PDB defaults, RBAC). Mode: report-only.

The constraint edit itself is correct, but the change is incomplete: the lock file and the operators chart version were not updated alongside it, so as committed the bump neither builds cleanly nor ships.

🔴 P0/P1 — must fix

• charts/clickstack-operators/Chart.lock:7 — The lock still records clickhouse-operator-helm 0.0.2 with a digest computed against the old ~0.0.2 block; it was not regenerated, so helm dependency build charts/clickstack-operators fails with the lock file (Chart.lock) is out of sync with the dependencies file (Chart.yaml) (reproduced empirically), and the locked 0.0.2 is now outside the new constraint — breaking the needs_operators full-stack integration suite that gates release.
  • Fix: Run helm dependency update charts/clickstack-operators to re-resolve to 0.0.5 and refresh the digest, then commit the regenerated Chart.lock.
  • _{correctness, reliability, testing, maintainability}
• charts/clickstack-operators/Chart.yaml:8 — The operators chart version: stays at 1.0.0; yarn run version runs scripts/update-chart-versions.js, which only rewrites ./charts/clickstack (line 6), so the operators chart version is never advanced, and helm/chart-releaser-action with skip_existing: true skips republishing the unchanged 1.0.0 — the dependency bump never reaches consumers even after the lock is fixed.
  • Fix: Bump charts/clickstack-operators/Chart.yaml version (e.g. to 1.1.0), and/or add ./charts/clickstack-operators to the charts array in scripts/update-chart-versions.js.
  • _{reliability, project-standards}

🟡 P2 — recommended

• .github/workflows/helm-test.yaml:38 — The fast PR lane only runs helm dependency build charts/clickstack; charts/clickstack-operators is never dependency-built or rendered in CI, so lock/Chart.yaml drift passes green and only surfaces in the slower full-stack Kind suite.
  • Fix: Add a step that runs helm dependency update charts/clickstack-operators && helm template charts/clickstack-operators >/dev/null (or a git diff --exit-code lock-drift check) so divergence fails the fast lane.
  • _{correctness, testing, reliability}

🔵 P3 nitpicks (4)

• .changeset/bump-clickhouse-operator-helm.md:7 — The changeset (which becomes the changelog) claims ~0.0.2 "resolved narrowly to v0.0.2 only (Masterminds semver behavior)", but Masterminds tilde expands ~0.0.2 to >=0.0.2 <0.1.0, which already includes 0.0.5; the actual pin is the committed lock, not the constraint.
  • Fix: Reword the changeset to attribute the pin to the stale Chart.lock rather than the tilde constraint.
• charts/clickstack-operators/Chart.yaml:16 — The open range >=0.0.5, <0.1.0 floats onto any future 0.0.x and is inconsistent with the sibling mongodb-kubernetes ~1.7.0 pinned style in the same file.
  • Fix: Consider ~0.0.5 for consistency and reproducibility, or document why this dependency intentionally floats.
• .changeset/bump-clickhouse-operator-helm.md:1 — Branch zeynel/bump-clickhouse-operator-helm does not use the warren/ prefix required by AGENTS.md Git Conventions.
  • Fix: Rename the branch to the documented prefix.
• .changeset/bump-clickhouse-operator-helm.md:1 — The changeset declares a minor bump while the commit/title use fix(...) (patch); minor is defensible given new CRD fields, but the signals disagree.
  • Fix: Align the commit type with the intended minor bump.

---

Reviewers (6): correctness, testing, maintainability, project-standards, reliability, learnings-researcher.

Testing gaps:

• No CI check asserts charts/clickstack-operators/Chart.lock is in sync with Chart.yaml, nor that the resolved operator version is >=0.0.5 — a stale lock pinning 0.0.2 passes unnoticed in the fast lane.
• No render/lint coverage exists for charts/clickstack-operators (no tests/ dir); the dependency bump is exercised only by the heavy full-stack Kind suite.
• Residual risk (out of scope, verify in release notes): subchart CRDs annotated helm.sh/resource-policy: keep are not upgraded by Helm, so adopters upgrading in place may run the v0.0.5 controller against v0.0.2 CRDs/RBAC.

[wrn14897]

hey @ZeynelKoca, thanks for the contribution. could you address the p0 commit? to rebuild the lock file