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: 7af0d22

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: 3 files changed against ca8c0dc — .changeset/bump-clickhouse-operator-helm.md (new), charts/clickstack-operators/Chart.lock, charts/clickstack-operators/Chart.yaml. A dependency-constraint widening for clickhouse-operator-helm (~0.0.2 → >=0.0.5, <0.1.0), lock regenerated to operator v0.0.6, chart version 1.0.0 → 1.1.0.

✅ No critical issues found. The semver widening is valid Masterminds syntax, Chart.lock (0.0.6) satisfies the new constraint, and the 1.0.0→1.1.0 minor bump is necessary so chart-releaser (skip_existing: true) republishes the operators chart. The committed changeset's claim that ~0.0.2 already expands to >=0.0.2,<0.1.0 is accurate.

🟡 P2 — recommended

• .changeset/bump-clickhouse-operator-helm.md:2 — The "helm-charts": minor changeset versions only charts/clickstack, not clickstack-operators, so on release it bumps and republishes the unrelated clickstack chart (3.0.0→3.1.0) and files this dependency change in the wrong chart's changelog, while the operators chart is versioned solely by the manual 1.1.0 edit.
  • Fix: Drop the changeset for this operators-only change (the manual 1.1.0 bump already drives chart-releaser), or confirm with maintainers whether an unrelated clickstack release is intended.
  • _{project-standards}

🔵 P3 nitpicks (1)

• charts/clickstack-operators/Chart.yaml:16 — The two dependencies use different notations for the same class of range (mongodb-kubernetes: "~1.7.0" vs clickhouse-operator-helm: ">=0.0.5, <0.1.0"), and for a 0.0.x version ~0.0.5 expands to the identical >=0.0.5, <0.1.0.
  • Fix: Use version: "~0.0.5" to match the sibling tilde notation while preserving the same resolved range.

---

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

Testing gaps: The dependency bump is already exercised by the kind-based full-stack integration suite (needs_operators: true runs helm dependency build + helm install on clickstack-operators via chart-test.yml); the fast helm-test.yaml signal and helm-unittest cover only charts/clickstack — a pre-existing gap this diff neither introduces nor worsens.

[wrn14897]

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

[ZeynelKoca]

@wrn14897 Done!