feat: add version probe job overrides

[ashishch432]

Why

Job metadata override and additional template spec inheritance

What

Adds a versionProbe field (type batchv1.JobTemplateSpec) to both ClickHouseClusterSpec and KeeperClusterSpec. User-provided values are applied as a strategic merge patch on top of the operator-generated Job, allowing overrides for any Job/Pod field:

• Metadata (labels, annotations) at both Job and Pod level
• Spec-level fields (resources, tolerations, ttlSecondsAfterFinished, etc.)

Scheduling fields (nodeSelector, tolerations, affinity, serviceAccountName, etc.) are also inherited from the cluster's PodTemplate.

Example

spec:
  versionProbe:
    metadata:
      annotations:
        sidecar.istio.io/inject: "false"

Related Issues

Fixes #128

[Copilot]

Pull request overview

Adds a versionProbe override mechanism to let users customize the operator’s version-probe Kubernetes Jobs (e.g., disable Istio sidecar injection) and inherits additional scheduling-related fields from the cluster PodTemplate.

Changes:

• Introduces spec.versionProbe (JobTemplateSpec) on ClickHouse/Keeper CRDs and passes it into version probe reconciliation.
• Implements strategic-merge-patch-based overrides for the generated version probe Job plus additional PodTemplate scheduling inheritance.
• Adds unit/integration tests and updates generated CRDs + API reference docs.

Reviewed changes

Copilot reviewed 12 out of 14 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
internal/controller/versionprobe.go	Adds VersionProbe override support (SMP) and inherits more PodTemplate scheduling fields for the probe Job.
internal/controller/versionprobe_test.go	New unit tests validating override merge semantics.
internal/controller/keeper/sync.go	Wires spec.versionProbe into the version probe config for Keeper.
internal/controller/keeper/controller_test.go	Adds integration test asserting override propagation + scheduling inheritance.
internal/controller/clickhouse/sync.go	Wires spec.versionProbe into the version probe config for ClickHouse.
internal/controller/clickhouse/controller_test.go	Adds integration test asserting override propagation + scheduling inheritance.
api/v1alpha1/clickhousecluster_types.go	Adds VersionProbe *batchv1.JobTemplateSpec to ClickHouseClusterSpec with schemaless preservation.
api/v1alpha1/keepercluster_types.go	Adds VersionProbe *batchv1.JobTemplateSpec to KeeperClusterSpec with schemaless preservation.
api/v1alpha1/zz_generated.deepcopy.go	Updates deep-copies for the new VersionProbe field.
docs/api_reference.md	Documents the new versionProbe field for both cluster specs.
config/crd/bases/clickhouse.com_clickhouseclusters.yaml	CRD schema update for spec.versionProbe.
config/crd/bases/clickhouse.com_keeperclusters.yaml	CRD schema update for spec.versionProbe.
dist/chart/templates/crd/clickhouseclusters.clickhouse.com.yaml	Helm chart CRD template update for spec.versionProbe.
dist/chart/templates/crd/keeperclusters.clickhouse.com.yaml	Helm chart CRD template update for spec.versionProbe.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[GrigoryPervakov]

I can't see a reason for the probe pod to be scheduled with the server's Affinity or TopologySpread settings. ServiceAccount also seems to be useless for it.
So I'd prefer to inherit only the required parameters from the server Pods and override the rest with the new field. Same for PriorityClassName/RuntimeClassName

[ashishch432]

Agreed on the fact some of the overrides aren't needed. For Service Account I remember doing it because imagePullSecrets may be tied to an SA, but super less likely practically with dedicated secret being present. A NodeSelector and Toleration may be reasonable defaults to inherit additionally - when choosing certain Node Pool to run the ClickHouse servers on.

But yeah, sensible to just inherit just the existing required parameters, will revert.

[GrigoryPervakov]

Why is Job-level metadata merged into Pod metadata?

[ashishch432]

Relic of the old PR, the intention was that labels and annotations can be set at both job and pod level and simple solution would be just to replicate it to both, instead of having 2 dedicate label and annotation overrides for the job and the pod.

If we go with a custom type, what do you think: Should label and annotation overrides just apply to the pod or the job or both. Or we should have overrides for each.
For example with Istio, labels and annotations are only work at the pod level (spec.template.metadata).

I'm not sure of use-cases for overriding the job level metadata.

[GrigoryPervakov]

I'm not sure about Schemaless fields. I'd prefer to introduce our own types, copying k8s structure, but with only supported fields. With SMP overrides, it should be easy to add new fields later

[ashishch432]

I see. In the previous PR we were looking to use batchv1.JobTemplateSpec as override, so went ahead with that.
But it's fine either way, for a simple version probe job it doesn't need too much flexibility.

Which fields do you think we should support in the custom type.
I can think of: Labels, Annotations (See the other comment on whether labels and annotations need to be job's or pod's), Resources. NodeSelector, Tolerations to start with.