Allow adding a label to all created resources with a configuration

[xstefank]

To basically label all resources belonging to a particular operator.

[cmoulliard]

It is perhaps not needed to label to which operator a resource belongs but at least to provide (like for SQL records):

• Creation and changing date
• System who created and changed the resource.
  The system should be named in a way that a user will understand immediately that the kube resource x.y.z has been changed by the pod a.b.c (= operator) from the namespace v.w

[xstefank]

@cmoulliard Operator doesn't need to run inside a pod and such information could be potentially considered a leak. I think allowing a custom label added to everything allows users to add whatever information they see fit but saying which pod/machine did the update can be potentially harmful.

[csviri]

Isn't the owner references (labels in different namespace) are enough to identify that (we already adding those).

[csviri]

Operator doesn't need to run inside a pod

where it would run if not inside a pod?

[xstefank]

Maybe I'm misunderstanding that it can run anywhere needed, but I might be just not seeing all the common use cases. So disregard it if operator usually runs in pod.

[cmoulliard]

Isn't the owner references (labels in different namespace) are enough to identify that (we already adding those).

Some resources are not owned at all by a parent resource.

[csviri]

Some resources are not owned at all by a parent resource.

Not, but usually those are not managed by the controller.

Typically config maps as input.

[csviri]

I don't mean that this is a bad idea, just want to understand the use case. Acually makes sense too see all the resources managed by a controller. And this might be fairly simple to implement under Dependent Resources, where we actually want such features.

[cmoulliard]

Here is a good example. The following secret is created from a controller but if you look to the content, there is no way to figure out such information.

kind: Secret
apiVersion: v1
metadata:
  name: openstack-cloud-credentials
  namespace: openshift-cluster-csi-drivers
  labels:
    cloudcredential.openshift.io/credentials-request: 'true'
  annotations:
    cloudcredential.openshift.io/credentials-request: openshift-cloud-credential-operator/openshift-cluster-csi-drivers
data:
  clouds.yaml: Y2xvdWRz...OiB0cnVlCg==
type: Opaque

To patch it you will have to do this BUT again I still don't know why pod did finally the job

$ oc edit secret openstack-credentials -n kube-system
# update clouds.yaml file

More detail about the use case is available here: https://that.guru/cookbooks/openshift/cinder-csi-driver/

[metacosm]

Operator doesn't need to run inside a pod

where it would run if not inside a pod?

well, when you test locally, it isn't for example, though, granted, that's not most of the time.

[metacosm]

Should that be implemented at the JOSDK level instead?

[csviri]

I was thinking maybe this could be kind of an apsect on top of all Dependent resource creation. So for ALL depdendets after desired state is object created it will be passed for a common "aspect" as HasMetadata that can add labels or do any modifications.