TEP-0041: Add TEP for Tekton Component Versioning #329

vinamra28 · 2021-02-01T14:47:09Z

Proposal to add versioning in Tekton components so that any system authenticated users who are having access to cluster may be able to view the version of Tekton component installed.

/kind tep

Signed-off-by: vinamra28 [email protected]

vinamra28 · 2021-02-02T13:23:54Z

Hi @imjasonh, as per yesterday's API call I explored the way how knative does or whether it does or not so in knative we get only the client version and which version it will support when we do

$ kn version
Version:      v20210201-5b7586b3
Build Date:   2021-02-01 10:43:49
Git Revision: 5b7586b3
Supported APIs:
* Serving
  - serving.knative.dev/v1 (knative-serving v0.20.0)
* Eventing
  - sources.knative.dev/v1alpha2 (knative-eventing v0.20.0)
  - eventing.knative.dev/v1beta1 (knative-eventing v0.20.0)

And for checking the version of knative components we do

kubectl get namespace knative-serving -o 'go-template={{index .metadata.labels "serving.knative.dev/release"}}'
kubectl get namespace knative-eventing -o 'go-template={{index .metadata.labels "eventing.knative.dev/release"}}'

where we again need to have access to get the namespace. They are not handling the case for whether all system:authenticated will be able to access the version of components.

/cc @vdemeester @piyush-garg

imjasonh · 2021-02-02T13:35:24Z

Hi @imjasonh, as per yesterday's API call I explored the way how knative does or whether it does or not so in knative we get only the client version and which version it will support when we do

They are not handling the case for whether all system:authenticated will be able to access the version of components.

Thanks, that's really helpful context. Do you know if they have had any issues with this in the past, and any solutions they've considered?

Could we grant system:authenticated read-only access to our namespaces, so every user can read the installed version? Is there a downside to that I'm not considering?

One reason I'm hesitant about adding a CRD for this is that it requires us to update the CRD in lock-step with the installed components, which themselves have to already be labeled in lock-step with actual binary releases. With each new moving piece it adds another opportunity to get things out of sync and confuse future debuggers. Add to that the complexity of defining (/versioning?) the new CRD type, granting the right users update and read access to it, etc., and it seems like a large hammer for this particular nail.

chmouel · 2021-02-02T14:05:29Z

Could we grant system:authenticated read-only access to our namespaces, so every user can read the installed version? Is there a downside to that I'm not considering?

Unfortunately, "enteprise" corporation running tekton usually lock down heavily their installations and rather have a policy of not letting that access.

I agree with you this bring much complexity and I am not so sure if the use case warrants it.

I think we may want to explain in the TEP why is it something that it is so important to be able to know the tekton components version in a locked down environment where the controllers are not readable.

imjasonh · 2021-02-02T14:08:16Z

Unfortunately, "enteprise" corporation running tekton usually lock down heavily their installations and rather have a policy of not letting that access.

That make sense. In that case, are we sure the same enterprise corporations want users to be able to determine the version (or existence) of a Tekton installation at all? 🤔

piyush-garg · 2021-02-08T05:36:40Z

Hi @imjasonh, as per yesterday's API call I explored the way how knative does or whether it does or not so in knative we get only the client version and which version it will support when we do
They are not handling the case for whether all system:authenticated will be able to access the version of components.

Thanks, that's really helpful context. Do you know if they have had any issues with this in the past, and any solutions they've considered?

Could we grant system:authenticated read-only access to our namespaces, so every user can read the installed version? Is there a downside to that I'm not considering?

If we want to provide read access to read the namespace or in the TEP, we mentioned a solution to keep the version information in a configmap, and the particular configmap can be provided read access for users, then we need to know the namespace where the installation is done to get the details. Like we have the use case of tekton-pipelines and openshift-pipelines namespace as of now, and there can be many more if the installation needs to be in a user-provided namespace.

One reason I'm hesitant about adding a CRD for this is that it requires us to update the CRD in lock-step with the installed components, which themselves have to already be labeled in lock-step with actual binary releases. With each new moving piece it adds another opportunity to get things out of sync and confuse future debuggers. Add to that the complexity of defining (/versioning?) the new CRD type, granting the right users update and read access to it, etc., and it seems like a large hammer for this particular nail.

The benefit we get with this is we can define it cluster-wide. For now, this can be only providing version information but in the future, it may be extended for providing other metadata information if required like minimum k8s version, etc.

pritidesai · 2021-02-08T17:09:05Z

assigning it to@ImJasonH @afrittoli

vinamra28 · 2021-02-08T17:19:44Z

/assign @afrittoli @imjasonh

vinamra28 · 2021-02-22T17:14:57Z

/test .*

vinamra28 · 2021-02-22T17:21:38Z

/cc @afrittoli @imjasonh
any updates/feedbacks?

vinamra28 · 2021-02-22T17:23:45Z

@vdemeester @bobcatfish can you also please review this as well? 🙂

bobcatfish · 2021-02-22T21:57:23Z

/assign

imjasonh · 2021-04-12T14:54:46Z

teps/0041-tekton-component-versioning.md

+
+#### Disadvantages
+
+1. User need to know the namespace in which Tekton components are installed


This seems like the smallest disadvantage of all the alternatives. Can we promote this to the proposed solution, and move the others to "alternatives considered" in a section below?

Unless there's disagreement, we can start working on this as the solution.

+1
from what we have seen, it is rare that the installation namespace get changed from the default one we provide for a platform.

There is no incentive for a user to do that, as long as we don't support/encourage multi-tenancy (say, more than one instances of pipeline controller in different namespace. 😇

bobcatfish · 2021-04-14T21:41:37Z

@vinamra28 another possible alternative, I noticed that knative handles this by adding a version label to every CRD they install (knative/serving#2820) so their docs recommend checking the version installed by getting the label from the namespace:

kubectl get namespace knative-serving -o 'go-template={{index .metadata.labels "serving.knative.dev/release"}}'

I'm wondering if maybe it would be more reasonable to require the CLI to be able to read labels on the namespace? (vs currently we require reading the Deployment?)

Sorry for the last minute alternative entry but im curious what you think! (probably worth adding as an alternative even if we don't pursue it - but if the CLI already needs read access to the namespace, this might be an ok alternative?)

But if that's no good, I'm 👍 to the configmap proposal!

afrittoli

This seems reasonable to me - it seems simple enough to implement.
Only version from releases will be available, but that is the same with the existing labels we have.

I would be nice to call out that this will require work on the release pipeline to be able to produce the config maps, as well as any relationship with operator, as already called out by @bobcatfish.

Since the proposal and design are already in, we could submit this a "implementable" directly I think.

teps/0041-tekton-component-versioning.md

afrittoli · 2021-04-15T10:51:38Z

teps/0041-tekton-component-versioning.md

+
+## Drawbacks
+
+## Alternatives


Could we provide a role & rolebinding as part of installing tekton that allows for read access to the existing version labels? if not, can the problem statement go into more detail about why this is not reasonable? it seems like we need to provide role and rolebinding regardless

I think this would require giving read access to the entire deployment?

vdemeester

@vinamra28 another possible alternative, I noticed that knative handles this by adding a version label to every CRD they install (knative/serving#2820) so their docs recommend checking the version installed by getting the label from the namespace:
kubectl get namespace knative-serving -o 'go-template={{index .metadata.labels "serving.knative.dev/release"}}'
I'm wondering if maybe it would be more reasonable to require the CLI to be able to read labels on the namespace? (vs currently we require reading the Deployment?)

Sorry for the last minute alternative entry but im curious what you think! (probably worth adding as an alternative even if we don't pursue it - but if the CLI already needs read access to the namespace, this might be an ok alternative?)

But if that's no good, I'm to the configmap proposal!

Note that this is really close to what we are doing today too (at least for tektoncd/pipeline and I think also for tektoncd/triggers), but not on the namespace. This probably reduce a little bit some rbac needs as it's probably more common to be able to list namespace than deployments in other namespace. But there is also a very high possibility that users cannot list namespace (or the list is filter to theirs).

On the proposed solution, there could be yet another alternative : make the mutating webhook append the version on object on creation (in an annotation). This would be easy to implement (we can pass the version info as a flag just like we do on the controller). The main disadvantages here is that to get information, the client (tkn, …) would need to create a resource (a dummy Task should suffice), which means that a user would need to have a list create access to Task to be able to get the version. Today, we are adding version as an annotation or a label on runs if I remember correctly.

vdemeester · 2021-04-16T03:40:39Z

teps/0041-tekton-component-versioning.md

+Basic test scenarios of getting the version information should be added in all the components.
+Other components like CLI can add the test cases based on their usage.
+
+## Design Evaluation


@bobcatfish of course, but I wonder what do you mean about this ? Operator folks are reviewer here as well, so they are/should be collaborating already 🙃
cc @tektoncd/experimental-maintainers

vinamra28 · 2021-04-19T13:17:27Z

On the proposed solution, there could be yet another alternative : make the mutating webhook append the version on object on creation (in an annotation). This would be easy to implement (we can pass the version info as a flag just like we do on the controller). The main disadvantages here is that to get information, the client (tkn, …) would need to create a resource (a dummy Task should suffice), which means that a user would need to have a list create access to Task to be able to get the version. Today, we are adding version as an annotation or a label on runs if I remember correctly.

@vdemeester another disadvantage which I can think of is that we cannot create a dummy resource for Dashboard and also there can be scenario when no Tekton resource is installed on the cluster in case of Pipelines or Triggers.

bobcatfish

i left a bunch of requests for tweaks to the TEP content but generally im in favor of this proposal!

/approve

bobcatfish · 2021-05-05T18:10:32Z

teps/0041-tekton-component-versioning.md

+
+## Requirements
+
+None


This proposal is to allow the system authenticated users of the cluster
to access the version of the Tekton component installed even if they don't
have proper rights to read the version from the controller deployments.

That text above ^^ i think would be great to move from the proposal section to the requirements, e.g.:

users can access information about the versions of installed tekton components:

they do not need to have read access to Deployments

< maybe we can elaborate on what access we do expect them to have? >

bobcatfish · 2021-05-05T18:11:54Z

teps/0041-tekton-component-versioning.md

+1. Tekton CLI will not be able to access the version information from previously
+   released tekton components without this functionality.
+
+2. Tekton CLI needs to handle backward compatibility,


does backward compatibility here mean the CLI needs to be able to read the versions of previously released components? Or does this mean it needs to gracefully error out when trying to read the version of previously released components? either way i think this point would be clearer with a bit more detail

bobcatfish · 2021-05-05T18:13:18Z

teps/0041-tekton-component-versioning.md

+## Design Details
+
+As discussed in the proposal the possible solutions with their
+`pros` and `cons` are:-


looks like this section is missing? i think the pros might be something like:

pros:

dont need to create and manage any new types

cons:

no guarantee that configmap and actual installed version will be in sync

maybe this can be merged with the advantages/disadvantages section below?

instead of pros and cons shall I rename to advantages and disadvantages?

bobcatfish · 2021-05-05T18:15:58Z

teps/0041-tekton-component-versioning.md

+1. Client will have to create a dummy Tekton resource in order to find the version.
+2. In case of `Dashboard` no dummy resource can be created.
+3. There can be a scenario where no Tekton resource is present on the cluster.
+


can we add an alternative where we take the same approach as knative and make the version information available in labels on the namespace? (https://knative.dev/docs/install/check-install-version/)

This approaches would work and wouldn't require to create a new resource (configMap). It is also really close to what we are doing now, a diff would only be the following for tektoncd/pipeline.

diff --git a/config/100-namespace.yaml b/config/100-namespace.yaml index 5254a8ce..043f30b1 100644 --- a/config/100-namespace.yaml +++ b/config/100-namespace.yaml @@ -19,3 +19,4 @@ metadata: labels: app.kubernetes.io/instance: default app.kubernetes.io/part-of: tekton-pipelines + pipeline.tekton.dev/release: "devel"

The problem is that only tektoncd/pipeline component defines this (applies the namespace) and if other component start to define this (in a 100-namespace.yaml file), the last installed component wins… The operator could help here, but the problem wouldn't be solved for when you install it on your own.

tekton-robot · 2021-05-05T18:16:27Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bobcatfish

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

~~teps/OWNERS~~ [bobcatfish]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Signed-off-by: vinamra28 <[email protected]>

vinamra28 · 2021-05-10T16:00:06Z

The PR is now ready for review
/cc @vdemeester @bobcatfish @afrittoli @imjasonh

nikhil-thomas · 2021-05-10T17:16:34Z

teps/0041-tekton-component-versioning.md

+1. User need to know the namespace in which Tekton components are installed
+   since the scope is only the namespace.
+
+2. No guarantee that `ConfigMap` and actual installed version will be in sync.


The syncing seems to be the job of tektoncd/operator.

The operator can sync the configmap(s) if it exist.

We can also think about letting the operator create the ConfigMaps.
Yes! this will make this solution dependent on our operator.
But, hey! the lifecycle management of TektonComponents are becoming more and more complex, and the operator could be the common agent which takes care of issues like the one addressed in this TEP.

In addition, operator can be the single point where we have to add this logic of creating/updating the ConfigMaps, instead of adding it to Pipeline, Triggers, Dashboard ...

nikhil-thomas · 2021-05-10T17:25:48Z

teps/0041-tekton-component-versioning.md

+### 3. Creating a CRD
+
+Tekton components should create a CRD which is to provide information like
+metadata about components.


Instead of creating, new CRDs, we can consider using already existing CRDs of operator for this purpose.
TektonPipeline, TektonTrigger, TektonDasboard ... which handle the lifecycle of the respective components.

In additon, Operator have also TektonConfig CRD. This CRD is an umbrella CRD which can install 1 or more TektonComponents.

We might be able to achieve what we want by giving access to the status subresource of 'instance' of these CRDs.

We cannot totally rely on operator's CRDs as it depends on users how are they installing Pipelines or Triggers.

piyush-garg · 2021-05-14T06:11:29Z

@bobcatfish @vinamra28 @vdemeester

We have this PR on the operator, in which it can be configured to install the pipeline in the user-provided namespace. tektoncd/operator#305 Posting it here, as it effects this TEP

nikhil-thomas · 2021-05-14T10:46:29Z

tektoncd/operator#305

hi, @piyush-garg, this pr just auto-creates the TektonConfig CRD instance, which will lead to installation of Tekton Components (pipeline, triggers, dashboard). The feature to change the targetnamespace existed already.

Before this PR our users had to install operator and create an instance of TektonConfig CRD (one of https://github.com/tektoncd/operator/tree/main/config/crs/kubernetes/config). This PR just elimitates 1 installation step.

Note 1: even with this feature and this PR, it is safe to assume that a vast majority of our users will not change the default namespace (per platform supported by operator) where the components are installed. At present, for Kubernetes builds tekton-pipelines and for OpenShift builds openshift-pipelines.

Note 2: This PR introduces a tekton-config-defaults config map. So in case of Auto-create TektonConfig, the default namespace can be read from the key DEFAULT_TARGET_NAMESPACE (with the right permission.)

nikhil-thomas · 2021-05-14T10:47:35Z

@sm43

afrittoli

Thanks for all the updates.
It feels like a good direction to take.
/lgtm

tekton-robot added the kind/tep Categorizes issue or PR as related to a TEP (or needs a TEP). label Feb 1, 2021

tekton-robot requested review from afrittoli and sm43 February 1, 2021 14:47

tekton-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Feb 1, 2021

vinamra28 changed the title ~~Add TEP for Tekton Component Versioning~~ TEP-0041 Add TEP for Tekton Component Versioning Feb 1, 2021

vinamra28 changed the title ~~TEP-0041 Add TEP for Tekton Component Versioning~~ TEP-0041: Add TEP for Tekton Component Versioning Feb 1, 2021

vinamra28 force-pushed the vinamra28/component-versioning-tep branch from 4ad12b5 to f5827f2 Compare February 1, 2021 16:21

tekton-robot requested review from piyush-garg and vdemeester February 2, 2021 13:23

Base automatically changed from master to main February 3, 2021 16:34

tekton-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Feb 5, 2021

tekton-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Feb 8, 2021

vinamra28 force-pushed the vinamra28/component-versioning-tep branch from 1ca1f0b to 1f3f0d1 Compare February 8, 2021 17:13

tekton-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Feb 8, 2021

vinamra28 force-pushed the vinamra28/component-versioning-tep branch from 1f3f0d1 to cb39711 Compare February 8, 2021 17:18

tekton-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Feb 8, 2021

tekton-robot assigned afrittoli and imjasonh Feb 8, 2021

tekton-robot requested a review from imjasonh February 22, 2021 17:21

tekton-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Mar 31, 2021

vinamra28 force-pushed the vinamra28/component-versioning-tep branch from ee626dd to 7fa14db Compare April 6, 2021 10:25

imjasonh reviewed Apr 12, 2021

View reviewed changes

vinamra28 force-pushed the vinamra28/component-versioning-tep branch from 7fa14db to 653c139 Compare April 12, 2021 16:25

afrittoli reviewed Apr 15, 2021

View reviewed changes

vdemeester reviewed Apr 16, 2021

View reviewed changes

vinamra28 force-pushed the vinamra28/component-versioning-tep branch 3 times, most recently from 23d701c to cd86e27 Compare April 26, 2021 19:42

bobcatfish reviewed May 5, 2021

View reviewed changes

tekton-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label May 5, 2021

vinamra28 force-pushed the vinamra28/component-versioning-tep branch from cd86e27 to 1010f87 Compare May 7, 2021 03:44

Add TEP for Tekton Component Versioning

eb26f66

Signed-off-by: vinamra28 <[email protected]>

vinamra28 force-pushed the vinamra28/component-versioning-tep branch from 1010f87 to eb26f66 Compare May 7, 2021 03:45

tekton-robot requested review from afrittoli, bobcatfish, imjasonh and vdemeester May 10, 2021 16:00

nikhil-thomas reviewed May 10, 2021

View reviewed changes

afrittoli reviewed May 19, 2021

View reviewed changes

tekton-robot added the lgtm Indicates that a PR is ready to be merged. label May 19, 2021

tekton-robot merged commit 40219d2 into tektoncd:main May 19, 2021


		#### Disadvantages

		1. User need to know the namespace in which Tekton components are installed


		## Requirements

		None

TEP-0041: Add TEP for Tekton Component Versioning #329

TEP-0041: Add TEP for Tekton Component Versioning #329

Conversation

vinamra28 commented Feb 1, 2021

vinamra28 commented Feb 2, 2021

imjasonh commented Feb 2, 2021

chmouel commented Feb 2, 2021 • edited Loading

imjasonh commented Feb 2, 2021

piyush-garg commented Feb 8, 2021 • edited Loading

pritidesai commented Feb 8, 2021

vinamra28 commented Feb 8, 2021

vinamra28 commented Feb 22, 2021

vinamra28 commented Feb 22, 2021

vinamra28 commented Feb 22, 2021

bobcatfish commented Feb 22, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bobcatfish commented Apr 14, 2021

afrittoli left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vdemeester left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vinamra28 commented Apr 19, 2021

bobcatfish left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tekton-robot commented May 5, 2021

vinamra28 commented May 10, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

piyush-garg commented May 14, 2021

nikhil-thomas commented May 14, 2021

nikhil-thomas commented May 14, 2021

afrittoli left a comment

Choose a reason for hiding this comment

chmouel commented Feb 2, 2021 •

edited

Loading

piyush-garg commented Feb 8, 2021 •

edited

Loading