From 8480bf42a7a2d534bccb993e4be710399a82f128 Mon Sep 17 00:00:00 2001
From: Andrea Frittoli <andrea.frittoli@gmail.com>
Date: Wed, 11 Jan 2023 14:28:46 +0000
Subject: [PATCH] [TEP-0128] Multiple Tekton instances per Cluster

TEP proposal about running multiple instances of Tekton Pipeline in
a single Tekton cluster.

Signed-off-by: Andrea Frittoli <andrea.frittoli@gmail.com>
---
 ...8-multiple-tekton-instances-per-cluster.md | 309 ++++++++++++++++++
 teps/README.md                                |   1 +
 2 files changed, 310 insertions(+)
 create mode 100644 teps/0128-multiple-tekton-instances-per-cluster.md

diff --git a/teps/0128-multiple-tekton-instances-per-cluster.md b/teps/0128-multiple-tekton-instances-per-cluster.md
new file mode 100644
index 000000000..3095f239b
--- /dev/null
+++ b/teps/0128-multiple-tekton-instances-per-cluster.md
@@ -0,0 +1,309 @@
+---
+status: proposed
+title: Multiple Tekton instances per cluster
+creation-date: '2023-01-11'
+last-updated: '2023-01-11'
+authors:
+- '@afrittoli'
+collaborators: []
+---
+
+# TEP-0128: Multiple Tekton instances per cluster
+
+<!-- toc -->
+- [Summary](#summary)
+- [Motivation](#motivation)
+  - [Goals](#goals)
+  - [Non-Goals](#non-goals)
+  - [Use Cases](#use-cases)
+  - [Requirements](#requirements)
+- [Proposal](#proposal)
+  - [Notes and Caveats](#notes-and-caveats)
+- [Design Details](#design-details)
+- [Design Evaluation](#design-evaluation)
+  - [Reusability](#reusability)
+  - [Simplicity](#simplicity)
+  - [Flexibility](#flexibility)
+  - [User Experience](#user-experience)
+  - [Performance](#performance)
+  - [Risks and Mitigations](#risks-and-mitigations)
+  - [Drawbacks](#drawbacks)
+- [Alternatives](#alternatives)
+- [Implementation Plan](#implementation-plan)
+  - [Test Plan](#test-plan)
+  - [Infrastructure Needed](#infrastructure-needed)
+  - [Upgrade and Migration Strategy](#upgrade-and-migration-strategy)
+  - [Implementation Pull Requests](#implementation-pull-requests)
+- [References](#references)
+<!-- /toc -->
+
+## Summary
+
+With the growth of [Tekton adoption][tekton-adoption], Tekton is now used as
+a foundation technology for several open source tools as well as commercial
+offerings.
+
+Users may want to adopt different tools that rely on Tekton and run them in
+the same kubernetes clusters. Since tools may not be aligned in the version
+and configuration of Tekton they depend on, the main roadblock today is the
+ability to run multiple different instances of Tekton in a single kubernetes
+cluster.
+
+## Motivation
+
+The Tekton controller provides some functionality towards the ability of
+running multiple instances in a single cluster, namely the ability to
+configure the Tekton controller to watch a single namespace for resources
+to be reconciled. This functionality is not properly documented and it does
+not include other Tekton controllers, such as the various controllers
+bundled in the Tekton webhook as well the remote resolution controller.
+
+### Goals
+
+- Allow multiple instances of Tekton Pipeline to run in single kubernetes
+  cluster, each responsible for a Tekton resources in a dedicated namespaces. Each
+  instance performs validation, resolution and execution and is configured
+  independently from the others. 
+- Allow multiple version of Tekton Pipeline to run in a single kubernetes cluster,
+  as long as there are no backward incompatible changes between the older and newer
+  versions.
+- Identify and configure cluster level resources in Tekton Pipelines, such as CRDs,
+  cluster roles and bindings and the conversion webhook, so that they can safely
+  shared across multiple Tekton instances.
+
+### Non-Goals
+
+- Support multiple instances of Tekton Triggers
+- Changes to the Tekton cli, dashboard, operator, results, chains, triggers to
+  support multiple instances / versions of Tekton pipeline. While some of these
+  may be desirable, they are not in scope for this TEP.
+
+### Use Cases
+
+- Run multiple tools that depend on Tekton in the same clusters. Different
+  tools may require different configurations and versions of Tekton
+- Run multiple instance of Tekton for development and testing purposes
+
+### Requirements
+
+- Each instance of Tekton is responsible (validation, resolution, execution)
+  for resources in a dedicated namespace
+- Each instance of Tekton is configured independently, which includes observability
+  targets
+- Each instance of Tekton does not have access to resources in namespaces it's
+  not responsible for
+
+## Proposal
+
+<!--
+This is where we get down to the specifics of what the proposal actually is.
+This should have enough detail that reviewers can understand exactly what
+you're proposing, but should not include things like API designs or
+implementation. The "Design Details" section below is for the real
+nitty-gritty.
+-->
+
+### Notes and Caveats
+
+<!--
+(optional)
+
+Go in to as much detail as necessary here.
+- What are the caveats to the proposal?
+- What are some important details that didn't come across above?
+- What are the core concepts and how do they relate?
+-->
+
+
+## Design Details
+
+<!--
+This section should contain enough information that the specifics of your
+change are understandable. This may include API specs (though not always
+required) or even code snippets. If there's any ambiguity about HOW your
+proposal will be implemented, this is the place to discuss them.
+
+If it's helpful to include workflow diagrams or any other related images,
+add them under "/teps/images/". It's upto the TEP author to choose the name
+of the file, but general guidance is to include at least TEP number in the
+file name, for example, "/teps/images/NNNN-workflow.jpg".
+-->
+
+
+## Design Evaluation
+<!--
+How does this proposal affect the api conventions, reusability, simplicity, flexibility
+and conformance of Tekton, as described in [design principles](https://github.com/tektoncd/community/blob/master/design-principles.md)
+-->
+
+### Reusability
+
+<!--
+https://github.com/tektoncd/community/blob/main/design-principles.md#reusability
+
+- Are there existing features related to the proposed features? Were the existing features reused?
+- Is the problem being solved an authoring-time or runtime-concern? Is the proposed feature at the appropriate level
+authoring or runtime?
+-->
+
+### Simplicity
+
+<!--
+https://github.com/tektoncd/community/blob/main/design-principles.md#simplicity
+
+- How does this proposal affect the user experience?
+- What’s the current user experience without the feature and how challenging is it?
+- What will be the user experience with the feature? How would it have changed?
+- Does this proposal contain the bare minimum change needed to solve for the use cases?
+- Are there any implicit behaviors in the proposal? Would users expect these implicit behaviors or would they be
+surprising? Are there security implications for these implicit behaviors?
+-->
+
+### Flexibility
+
+<!--
+https://github.com/tektoncd/community/blob/main/design-principles.md#flexibility
+
+- Are there dependencies that need to be pulled in for this proposal to work? What support or maintenance would be
+required for these dependencies?
+- Are we coupling two or more Tekton projects in this proposal (e.g. coupling Pipelines to Chains)?
+- Are we coupling Tekton and other projects (e.g. Knative, Sigstore) in this proposal?
+- What is the impact of the coupling to operators e.g. maintenance & end-to-end testing?
+- Are there opinionated choices being made in this proposal? If so, are they necessary and can users extend it with
+their own choices?
+-->
+
+### Conformance
+
+<!--
+https://github.com/tektoncd/community/blob/main/design-principles.md#conformance
+
+- Does this proposal require the user to understand how the Tekton API is implemented?
+- Does this proposal introduce additional Kubernetes concepts into the API? If so, is this necessary?
+- If the API is changing as a result of this proposal, what updates are needed to the
+[API spec](https://github.com/tektoncd/pipeline/blob/main/docs/api-spec.md)?
+-->
+
+### User Experience
+
+<!--
+(optional)
+
+Consideration about the user experience. Depending on the area of change,
+users may be Task and Pipeline editors, they may trigger TaskRuns and
+PipelineRuns or they may be responsible for monitoring the execution of runs,
+via CLI, dashboard or a monitoring system.
+
+Consider including folks that also work on CLI and dashboard.
+-->
+
+### Performance
+
+<!--
+(optional)
+
+Consider which use cases are impacted by this change and what are their
+performance requirements.
+- What impact does this change have on the start-up time and execution time
+of TaskRuns and PipelineRuns?
+- What impact does it have on the resource footprint of Tekton controllers
+as well as TaskRuns and PipelineRuns?
+-->
+
+### Risks and Mitigations
+
+<!--
+What are the risks of this proposal and how do we mitigate? Think broadly.
+For example, consider both security and how this will impact the larger
+Tekton ecosystem. Consider including folks that also work outside the WGs
+or subproject.
+- How will security be reviewed and by whom?
+- How will UX be reviewed and by whom?
+-->
+
+Custom Resource Definitions are cluster scoped resources, which means that
+some parts of Tekton must be shared across multiple instances of Tekton.
+Constraints on the version of Tekton can be used to reduce the risk introduced
+by this. Adoption of "v1" will help here, since no backward compatible changes
+are allowed in the CRD definitions at all.
+
+### Drawbacks
+
+<!--
+Why should this TEP _not_ be implemented?
+-->
+
+## Alternatives
+
+<!--
+What other approaches did you consider and why did you rule them out? These do
+not need to be as detailed as the proposal, but should include enough
+information to express the idea and why it was not acceptable.
+-->
+
+
+## Implementation Plan
+
+<!--
+What are the implementation phases or milestones? Taking an incremental approach
+makes it easier to review and merge the implementation pull request.
+-->
+
+
+### Test Plan
+
+<!--
+Consider the following in developing a test plan for this enhancement:
+- Will there be e2e and integration tests, in addition to unit tests?
+- How will it be tested in isolation vs with other components?
+
+No need to outline all the test cases, just the general strategy. Anything
+that would count as tricky in the implementation and anything particularly
+challenging to test should be called out.
+
+All code is expected to have adequate tests (eventually with coverage
+expectations).
+-->
+
+### Infrastructure Needed
+
+<!--
+(optional)
+
+Use this section if you need things from the project or working group.
+Examples include a new subproject, repos requested, GitHub details.
+Listing these here allows a working group to get the process for these
+resources started right away.
+-->
+
+### Upgrade and Migration Strategy
+
+<!--
+(optional)
+
+Use this section to detail whether this feature needs an upgrade or
+migration strategy. This is especially useful when we modify a
+behavior or add a feature that may replace and deprecate a current one.
+-->
+
+### Implementation Pull Requests
+
+<!--
+Once the TEP is ready to be marked as implemented, list down all the GitHub
+merged pull requests.
+
+Note: This section is exclusively for merged pull requests for this TEP.
+It will be a quick reference for those looking for implementation of this TEP.
+-->
+
+## References
+
+<!--
+(optional)
+
+Use this section to add links to GitHub issues, other TEPs, design docs in Tekton
+shared drive, examples, etc. This is useful to refer back to any other related links
+to get more details.
+-->
+
+[tekton-adoption]: https://github.com/tektoncd/community/blob/main/adopters.md
\ No newline at end of file
diff --git a/teps/README.md b/teps/README.md
index 0f3cb11d6..7712fe88e 100644
--- a/teps/README.md
+++ b/teps/README.md
@@ -294,3 +294,4 @@ This is the complete list of Tekton teps:
 |[TEP-0124](0124-distributed-tracing-for-tasks-and-pipelines.md) | Distributed tracing for Tasks and Pipelines | implementable | 2022-10-16 |
 |[TEP-0125](0125-add-credential-filter-to-entrypoint-logger.md) | Add credential filter to entrypoint logger | proposed | 2022-10-27 |
 |[TEP-0127](0127-larger-results-via-sidecar-logs.md) | Larger Results via Sidecar Logs | implemented | 2022-12-15 |
+|[TEP-0128](0128-multiple-tekton-instances-per-cluster.md) | Multiple Tekton instances per cluster | proposed | 2023-01-11 |