Allow set extra labels/annotations

[andriishestakov]

Problem

Solution

Testing

Release Notes

[Uburro]

User labels can hijack selector labels and permanently wedge the StatefulSet. Every render does maps.Copy(labels, X.Labels) after building the operator's labels, so user keys win - but the selector is built separately from matchLabels, which is not updated. Setting extraLabels: {app.kubernetes.io/component: foo} (or name/instance, or slurm.nebius.ai/nodeset) makes the pod template diverge from the immutable selector.

[Uburro]

The spool PVC doc comment doesn't match the behavior. Both CRD fields say "added to every Pod and the spool PVC of this cluster", but nothing in the operator labels a PVC: common/volume.go:46-60 (the VolumeClaimTemplates, including the worker spool) is untouched. The only PVC labeling is chart-side in pvc.yaml, which iterates .Values.volumeSources with createPVC — jail and friends, not spool, and driven by chart values rather than the CR field. If the use case is billing attribution, unlabeled operator-created PVCs are probably the most valuable remaining gap; either way the comment should be corrected.

[Uburro]

ActiveCheck can use spool PVC. It needs to be rewritten.

[asteny]

@andriishestakov Hi!

The selector-label collision and PVC coverage from the previous review are now addressed in the rendering layer. There are still several reconciliation issues to resolve before this can be merged:

1. Existing Deployment-backed components will not receive new labels or annotations. DeploymentReconciler.patch copies only Spec.Template.Spec and does not copy Spec.Template.ObjectMeta. This affects accounting, REST, exporter, and sconfigcontroller.

2. Existing ActiveCheck CronJobs will not receive the metadata either. CronJobReconciler.patch copies only the pod spec and ignores CronJob labels, JobTemplate metadata, and PodTemplate metadata.

3. Existing MariaDB resources will not receive PodMetadata changes because MariaDbReconciler.patch does not reconcile Spec.PodTemplate.

4. extraAnnotations can overwrite the operator-owned slurm.nebius.ai/activecheck annotation. The ActiveCheck controller relies on this annotation to associate pods with checks. Operator-owned annotation keys must take precedence, similarly to protected labels.

5. Removing an extra annotation does not remove it from StatefulSet pod templates. Both StatefulSet reconcilers only copy desired keys into the existing map, so deleted custom annotations remain indefinitely. Please define and implement proper ownership/removal semantics.

Please add reconciliation tests that create an existing resource, update extraLabels/extraAnnotations, reconcile it, and verify that additions, changes, removals, and protected-key collisions behave correctly. Renderer-only tests do not cover these issues.

The PR also currently conflicts with main and its Problem/Solution/Testing/Release Notes sections are empty. Please resolve the conflicts and complete the description before merge.

Thanks!