Proposal: Use standard k8s labels

[eddycharly]

What

Use standard/recommended k8s labels to identify applications/components resources (https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/)

Why

Tekton applications need to find resources belonging to other applications (dashboard needs to talk to pipelines and triggers, triggers needs to talk to pipelines, etc.).

The current process for identifying resources in dependent applications is lacking flexibility, often relying on resource names (see https://github.com/tektoncd/dashboard/blob/83f7c6a9746470f5fb391a160779d855f8db8e00/pkg/endpoints/dashboard.go#L110-L130 for example).

Also, version labels are not completely clear to me:

pipeline/config/controller.yaml

Lines 23 to 24 in c11c6af

	pipeline.tekton.dev/release: "devel"
	version: "devel"

What is the difference between pipeline.tekton.dev/release and version ?

How

We could establish a clear list of applications/components labels and document them.
These labels should be set on all resources and we should use them to lookup the necessary resources instead of relying on names.

Such a list could look something like this:

application	component	app.kubernetes.io/name	app.kubernetes.io/component	app.kubernetes.io/version
pipelines	controller	tekton-pipelines	controller	v0.11.3
pipelines	webhook	tekton-pipelines	webhook	v0.11.3
triggers	controller	tekton-triggers	controller	v0.4.0
triggers	webhook	tekton-triggers	webhook	v0.4.0
dashboard	controller	tekton-dashboard	controller	v0.6.1
webhooks-extension	extension	tekton-webhooks-extension	extension	v0.6.1
webhooks-extension	validator	tekton-webhooks-extension	validator	v0.6.1

Other labels (app.kubernetes.io/instance, app.kubernetes.io/part-of, and app.kubernetes.io/managed-by) could be used to reflect the deployment instance and the technology used to deploy (kubectl/helm).

Benefits

The benefits would be:

• Normalized labelling
• More flexible lookup process
• Easy to document/test

[vdemeester]

In general, I am +:100: on this :wink:

Also, version labels are not completely clear to me:

pipeline/config/controller.yaml

Lines 23 to 24 in c11c6af

	pipeline.tekton.dev/release: "devel"
	version: "devel"

What is the difference between pipeline.tekton.dev/release and version ?

None, and if we would follow k8s labels, we would add one more. pipeline.tekton.dev/release is an internal label (let's say 😅), version is the label that follows istio guidelines (see https://istio.io/docs/ops/deployment/requirements/).

The benefits would be:

* Normalized labelling
* More flexible lookup process
* Easy to document/test

/kind feature
/kind cleanup

[eddycharly]

None, and if we would follow k8s labels, we would add one more. pipeline.tekton.dev/release is an internal label (let's say 😅), version is the label that follows istio guidelines (see https://istio.io/docs/ops/deployment/requirements/).

Thanks for clearing this up.
As it is specific to istio, it should ultimately be the responsibility of the end user to set them i guess, and should not participate in the context of looking up resources.

Reading the k8s docs again i wonder if the labels should be (tekton-pipelines controller example)

labels:
  app.kubernetes.io/name: tekton-pipelines
  app.kubernetes.io/component: controller

or

labels:
  app.kubernetes.io/name: controller
  app.kubernetes.io/part-of: tekton-pipelines

The second one looks closer to the docs. If we use this, we probably should omit the app.kubernetes.io/component label as it doesn't really bring any more infos.

[eddycharly]

/assign

[eddycharly]

Closing as all related PRs were merged.