Define Required Metadata Labels on deployment definitions

[kristinochka]

Is your enhancement related to a problem? Please describe.

The labels that Kubernetes recommends provide useful identification information used by Kubernetes, users of the cluster, and other resources.
Following files do not have required Kubernetes metadata labels:

deploy/cluster_role.yaml
deploy/cluster_role_binding.yaml

"app.kubernetes.io/instance" "app.kubernetes.io/managed-by" "app.kubernetes.io/name" labels are missing.

Describe the solution you'd like

Example how this can be fixed:

metadata:
  labels:
    app.kubernetes.io/instance: my-instance
    app.kubernetes.io/managed-by: my-heritage
    app.kubernetes.io/name: my-name
    helm.sh/chart: my-chart

Describe alternatives you've considered

Additional context

[tolusha]

@kristinochka
Could you clarify why cluster role/binding should not have default kubernetes labels ?

[kristinochka]

Not sure I follow your question. This ticket says cluster_role.yaml and cluster_role_binding.yaml should have labels.

[tolusha]

@kristinochka
sorry, I misread the description.

[kristinochka]

I noticed there are a few other files are missing ["app.kubernetes.io/instance" "app.kubernetes.io/managed-by" "app.kubernetes.io/name"] labels under metadata.labels

deploy/role.yaml
deploy/role_binding.yaml
deploy/role_binding_oauth.yaml
deploy/service_account.yaml
deploy/operator.yaml
deploy/crds/org_v1_che_cr.yaml
deploy/crds/org_v1_che_crd.yaml

[tolusha]

@kristinochka
There is another question
When Eclipse Che/CRW is deployed using OperatorHub
Some resources are created by olm and don't have required labels.

[kristinochka]

You mean resources that are not controlled by che-operator?

[tolusha]

Correct, for instance when Eclipse Che/CRW is deployed from OperatorHub then clusterrolebinding, serviceaccount, subscription.. etc are created by OLM and not by operator.

Another point all resources declared in #18357 (comment) are created during deployment but aren't managed by operator. From my point of view app.kubernetes.io/managed-by should be avoided in this case.

[kristinochka]

For resources which are managed by olm (and not your operator), the recommendation is to use the following annotation: app.kubernetes.io/managed-by: olm