vmware-archive / operator-builder

A Kubebuilder plugin to accelerate the development of Kubernetes operators
MIT License
41 stars 6 forks source link

bug: changing managed labels on component resource does not queue reconciliation #267

Open scottd018 opened 2 years ago

scottd018 commented 2 years ago

Consider the following:

apiVersion: tenancy.acme.com/v1alpha1
kind: TenancyCommon
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"tenancy.acme.com/v1alpha1","kind":"TenancyCommon","metadata":{"annotations":{},"name":"tenancycommon-sample"},"spec":{"collection":{"name":"cloudnativeplatform-sample-2","namespace":""}}}
  creationTimestamp: "2022-02-08T12:15:04Z"
  finalizers:
  - tenancy.acme.com/Finalizer
  generation: 2
  labels:
    test: label

Which has a child resource of Namespace:

apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: "2022-02-08T12:15:04Z"
  labels:
    kubernetes.io/metadata.name: tenancy-system-2
    workload-collection: debug4

Which has the code of the following:

    var resourceObj = &unstructured.Unstructured{
        Object: map[string]interface{}{
            "apiVersion": "v1",
            "kind":       "Namespace",
            "metadata": map[string]interface{}{
                //+docs: Defines the namespace in which all resources of this
                // component belong
                "name": collection.Spec.Test.Namespace, //  controlled by collection field: test.namespace
                "labels": map[string]interface{}{
                    "workload-collection": collection.Spec.CollectionLabel, //  controlled by collection field: collectionLabel
                },
            },
        },
    }

Notice the metadata.labels.workload-collection field is managed. When changing that, one would expect a reconciliation event to occur because that field is managed by the collection. However, this is not the case and editing the field directly on a child resource of a component does not queue reconciliation.