feat(crd): allow child resources to get additional labels and annotations

[gdsoumya]

This PR adds an optional flag in the CRD to pass down the metadata(labels and annotations) of the CR to the child resources. This allows for any custom tracking labels/annots to be passed down to the child resources

[gdsoumya]

@Abhra303 opened a PR directly instead of creating an issue. I know there's another PR #362 that adds something similar but it inherits the values to both the pod and sts. In our usecase we just want the tracking annotations/labels to be passed down to the main child resources managed by the CRD and not to the pods itself.

[Pinimo]

Hi! I personally like this PR's idea better than #362 (mine 😅). However, it looks like it is still lacking some tests. If you need, you can copy/adapt them from my PR 😉

[gdsoumya]

Thanks for the pointers @Pinimo ! Will add some tests!

[Abhra303]

On second thought, I think you are right to have a field for this. But in general, I prefer a clear and specific field for this. E.g.

spec:
  resourcesMetadata:
    labels: ...
    annotations: ...

I don't think it is common to pass labels/annotations down to its owned resources directly from CRD's metadata. What do you think?

[gdsoumya]

I don't think it is common to pass labels/annotations down to its owned resources directly from CRD's metadata. What do you think?

I have seen some operators pass down the labels and annotations on the parent resource specially if there's not concept of template like in case of deployments/sts etc.

I would have gone for a separate field but i think it'll just confuse people with the existing Spec.labels applied to pods directly. Which is why I had the original field to optionally inherit the labels which makes it an explicit user choice to reuse the parents metadata for all child resources and not just the sts.

Unless we want to introduce breaking change and have a separate spec for pod and sts like we have serviceSpec I would suggest reverting the last commit to have the optional flag to inherit and let users choose the behaviour for all direct child resources and they can specify any specific metadata for pods/service inside the existing spec fields.

[Abhra303]

Honestly, the existing spec.Labels is confusing anyway (and should be migrated to more pod specific fields instead) because it doesn't say it target pods specifically. I am not in favour of passing down metadata because users then will not able to configure the CRD when they need both cases - (i) unique labels to identify the CRD along with (ii) some common labels for all the resources it owns.

For example:

metadata:
  labels:
    operator: "dragonfly"
    crd-group: db
spec:
  ownedObjectsMetadata:
    labels:
      operator: "dragonfly"
    ...

Also the reconciler listens to spec changes only. So if you change the metadata of CRD, the reconciler won't be triggered and owned resources will not have the updated metadata labels.

[gdsoumya]

Okay then I will go ahead and add this field,

  ownedObjectsMetadata:
    annotations:
       .......
    labels:
       .......

For the existing spec.Labels I will leave it as is, I don't want to stretch the scope of this PR so maybe a followup to change it to spec.podSpec.labels and deprecating old field will be better

[gdsoumya]

@Abhra303 updated

[Abhra303]

Thanks!

[gdsoumya]

@Abhra303 seems like the CI started failing. it's failing on main too https://github.com/dragonflydb/dragonfly-operator/actions/runs/17944604330/job/51027928621

Don't think the failure is related to my changes. Can you please take a look

[Abhra303]

Yea, it is not related to your change. I'll look.

[Abhra303]

@gdsoumya, now the test is timing out, can you please check?

[gdsoumya]

Pushed fix, hopefully CI will pass now

[gdsoumya]

@Abhra303 it passed!

[Abhra303]

Thanks!

[gdsoumya]

@Abhra303 any eta on a new release with this change?