-
Notifications
You must be signed in to change notification settings - Fork 222
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
351 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,351 @@ | ||
| --- | ||
| title: tep-template | ||
| authors: | ||
| - "@kbaig" | ||
| creation-date: 2020-07-14 | ||
| last-updated: 2020-07-14 | ||
| status: proposed | ||
| --- | ||
| <!-- | ||
| **Note:** When your TEP is complete, all of these comment blocks should be removed. | ||
| To get started with this template: | ||
| - [ ] **Fill out this file as best you can.** | ||
| At minimum, you should fill in the "Summary", and "Motivation" sections. | ||
| These should be easy if you've preflighted the idea of the TEP with the | ||
| appropriate Working Group. | ||
| - [ ] **Create a PR for this TEP.** | ||
| Assign it to people in the SIG that are sponsoring this process. | ||
| - [ ] **Merge early and iterate.** | ||
| Avoid getting hung up on specific details and instead aim to get the goals of | ||
| the TEP clarified and merged quickly. The best way to do this is to just | ||
| start with the high-level sections and fill out details incrementally in | ||
| subsequent PRs. | ||
| Just because a TEP is merged does not mean it is complete or approved. Any TEP | ||
| marked as a `proposed` is a working document and subject to change. You can | ||
| denote sections that are under active debate as follows: | ||
| ``` | ||
| <<[UNRESOLVED optional short context or usernames ]>> | ||
| Stuff that is being argued. | ||
| <<[/UNRESOLVED]>> | ||
| ``` | ||
| When editing TEPS, aim for tightly-scoped, single-topic PRs to keep discussions | ||
| focused. If you disagree with what is already in a document, open a new PR | ||
| with suggested changes. | ||
| If there are new details that belong in the TEP, edit the TEP. Once a | ||
| feature has become "implemented", major changes should get new TEPs. | ||
| The canonical place for the latest set of instructions (and the likely source | ||
| of this file) is [here](/teps/NNNN-TEP-template/README.md). | ||
| --> | ||
| # TEP-000X: Introducing TriggerCRD | ||
|
|
||
| <!-- | ||
| This is the title of your TEP. Keep it short, simple, and descriptive. A good | ||
| title can help communicate what the TEP is and should be considered as part of | ||
| any review. | ||
| --> | ||
|
|
||
| <!-- | ||
| A table of contents is helpful for quickly jumping to sections of a TEP and for | ||
| highlighting any additional information provided beyond the standard TEP | ||
| template. | ||
| Ensure the TOC is wrapped with | ||
| <code><!-- toc --&rt;<!-- /toc --&rt;</code> | ||
| tags, and then generate with `hack/update-toc.sh`. | ||
| --> | ||
|
|
||
| <!-- toc --> | ||
| - [Summary](#summary) | ||
| - [Motivation](#motivation) | ||
| - [Goals](#goals) | ||
| - [Non-Goals](#non-goals) | ||
| - [Requirements](#requirements) | ||
| - [Proposal](#proposal) | ||
| - [Trigger CRD](#trigger-crd) | ||
| - [Trigger Status](#trigger-status) | ||
| - [EventListener CRD](#eventlistener-crd) | ||
| - [Path base EventListener CRD](#path-base-eventlistener) | ||
| - [User Stories (optional)](#user-stories-optional) | ||
| - [Story 1](#story-1) | ||
| - [Story 2](#story-2) | ||
| - [Notes/Constraints/Caveats (optional)](#notesconstraintscaveats-optional) | ||
| - [Risks and Mitigations](#risks-and-mitigations) | ||
| - [User Experience (optional)](#user-experience-optional) | ||
| - [Performance (optional)](#performance-optional) | ||
| - [Design Details](#design-details) | ||
| - [Test Plan](#test-plan) | ||
| - [Drawbacks](#drawbacks) | ||
| - [Alternatives](#alternatives) | ||
| - [Infrastructure Needed (optional)](#infrastructure-needed-optional) | ||
| - [Upgrade & Migration Strategy (optional)](#upgrade--migration-strategy-optional) | ||
| <!-- /toc --> | ||
|
|
||
| ## Summary | ||
|
|
||
| <!-- | ||
| This section is incredibly important for producing high quality user-focused | ||
| documentation such as release notes or a development roadmap. It should be | ||
| possible to collect this information before implementation begins in order to | ||
| avoid requiring implementors to split their attention between writing release | ||
| notes and implementing the feature itself. | ||
| A good summary is probably at least a paragraph in length. | ||
| Both in this section and below, follow the guidelines of the [documentation | ||
| style guide]. In particular, wrap lines to a reasonable length, to make it | ||
| easier for reviewers to cite specific portions, and to minimize diff churn on | ||
| updates. | ||
| [documentation style guide]: https://github.com/kubernetes/community/blob/master/contributors/guide/style-guide.md | ||
| --> | ||
| This proposal is to extract out Trigger definition from EventListener Spec into its own CRD | ||
| to resolve the problem of Multitenant EventListener. | ||
|
|
||
| This is a TEP for the implementation of the Trigger CRD that were | ||
| discussed in the following docs: | ||
|
|
||
| - [Trigger Listener CRDs](https://docs.google.com/document/d/1zUVrIbGZh2R9dawKQ9Hm1Cx3GevKIfOcRO3fFLdmBDc/edit#heading=h.tp9mko2koenr) | ||
| - [Multitenant EventListener](https://docs.google.com/document/d/1NX0ExhPad6ixTM8AdU0b6Vc3MVD5hQ_vIrOs9dIXq-I/edit) | ||
|
|
||
| ## Motivation | ||
|
|
||
| <!-- | ||
| This section is for explicitly listing the motivation, goals and non-goals of | ||
| this TEP. Describe why the change is important and the benefits to users. The | ||
| motivation section can optionally provide links to [experience reports][] to | ||
| demonstrate the interest in a TEP within the wider Tekton community. | ||
| [experience reports]: https://github.com/golang/go/wiki/ExperienceReports | ||
| --> | ||
| Today, EventListener commonly are created for every namespace and handle TriggerBinding and | ||
| TriggerTemplate in that same namespace. Creation of EventListener causes pod proliferation. For | ||
| every namespace that requires handling of webhook, we need EventListener which in turns lead to | ||
| this pod proliferation and causes excess resource consumption. | ||
|
|
||
| ### Goals | ||
|
|
||
| <!-- | ||
| List the specific goals of the TEP. What is it trying to achieve? How will we | ||
| know that this has succeeded? | ||
| --> | ||
| 1. Reduction in resource cosumption due to EventListener. | ||
| 2. Ability to have single EventListener to cater to whole cluster. | ||
|
|
||
| ### Non-Goals | ||
|
|
||
| <!-- | ||
| What is out of scope for this TEP? Listing non-goals helps to focus discussion | ||
| and make progress. | ||
| --> | ||
| How to create Multitenant EventListener resource with appropriate permissions won't be part of this proposal. | ||
| This will be handled by operator or admin of the cluster. | ||
|
|
||
| ## Requirements | ||
|
|
||
| <!-- | ||
| List the requirements for this TEP. | ||
| --> | ||
| 1. Add a new CRD Trigger which will be extracted from Trigger definition in EventListener Spec. | ||
| 2. Bind this Trigger CRD to EventListener. | ||
| 3. Ability to run Trigger resource in a different namespace from EventListener namespace. | ||
|
|
||
| ## 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. | ||
| --> | ||
| EventListener CRD will be split into two - a Trigger CRD and a EventListener CRD. | ||
|
|
||
| ### Trigger CRD | ||
| A single Trigger defines configuration for processing events i.e. it consists of TriggerBindings, | ||
| a single TriggerTemplate, and optionally interceptors and a serviceAccount. | ||
| ``` | ||
| apiVersion: v1alpha1 | ||
| kind: Trigger | ||
| metadata: | ||
| name: my-repo-trigger | ||
| spec: | ||
| serviceAccountName: "blah" | ||
| interceptors: | ||
| cel: | ||
| filter: "$(header.eventType == "push")" | ||
| bindings: | ||
| - name: key | ||
| value: "$(body.commit_id)" | ||
| template: "ref-to-my-template" | ||
| status: | ||
| address: | ||
| url: "el-my-svc.cluster.local" # could also be an IP address? | ||
| conditions: | ||
| status: True | ||
| message: "Bound to EventListener my-el" | ||
| ``` | ||
|
|
||
| #### Trigger Status | ||
| Trigger status will report url of EventListener bound and EventListener information to | ||
| which it is bound. | ||
|
|
||
| ### EventListener CRD | ||
| EventListeners expose an addressable "Sink" to which incoming events in the form of HTTP requests | ||
| are directed and process those requests with configuration from bound Triggers. Boundnamespace acts | ||
| as selector based on namespace. All triggers in namespaces specified are selected can be served by | ||
| EventListener. | ||
|
|
||
| ``` | ||
| apiVersion: v1alpha1 | ||
| kind: EventListener | ||
| metadata: | ||
| name: my-repo-trigger | ||
| spec: | ||
| serviceAccountName: "blah" | ||
| boundnamespace: | ||
| - foo-ns | ||
| - bar-ns | ||
| ``` | ||
|
|
||
| ### Path based EventListener | ||
| Inside EventListener, we will deduce Trigger to execute based on the path of the request URL. | ||
| To refer to trigger resource foo in namespace bar, we would url ```/bar/foo```. Instead of | ||
| EventListener iterating through every Triggers that can be serve by EventListener, EventListener | ||
| will directly process the Trigger refer by URL. | ||
|
|
||
| ### User Stories (optional) | ||
|
|
||
| <!-- | ||
| Detail the things that people will be able to do if this TEP is implemented. | ||
| Include as much detail as possible so that people can understand the "how" of | ||
| the system. The goal here is to make this feel real for users without getting | ||
| bogged down. | ||
| --> | ||
|
|
||
| #### Trigger CRD Implmentation | ||
| Trigger CRD will be implemented. Trigger CRD spec will contain serviceaccount, triggerbinding, | ||
| triggertemplate and interceptor. ServiceAccount will be optional. If not defined, ServiceAccount | ||
| of EventListener will be used. | ||
|
|
||
| #### EventListener Selector Implementation | ||
| Selector based EventListener implementation will be introduced. All namespace matching the | ||
| boundnamespaces in EventListener will be served by EventListener. | ||
|
|
||
| #### Path Base EventListener Implementation | ||
| Path base EventListener will be implemented. | ||
|
|
||
| ### Notes/Constraints/Caveats (optional) | ||
|
|
||
| <!-- | ||
| What are the caveats to the proposal? | ||
| What are some important details that didn't come across above. | ||
| Go in to as much detail as necessary here. | ||
| This might be a good place to talk about core concepts and how they relate. | ||
| --> | ||
|
|
||
| ### 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 | ||
| kubernetes ecosystem. | ||
| How will security be reviewed and by whom? | ||
| How will UX be reviewed and by whom? | ||
| Consider including folks that also work outside the WGs or subproject. | ||
| --> | ||
|
|
||
| ### User Experience (optional) | ||
|
|
||
| <!-- | ||
| Consideration about the user experience. Depending on the area of change, | ||
| users may be task and pipeline editors, they may trigger task and pipeline | ||
| runs 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) | ||
| Path base EventListener will improve the performance of EventListener by directly targetting | ||
| the trigger definition we want to target instead of needlessly processing trigger that we don't. | ||
| <!-- | ||
| Consideration about performance. | ||
| What impact does this change have on the start-up time and execution time | ||
| of task and pipeline runs? What impact does it have on the resource footprint | ||
| of Tekton controllers as well as task and pipeline runs? | ||
| Consider which use cases are impacted by this change and what are their | ||
| performance requirements. | ||
| --> | ||
|
|
||
| ## 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. | ||
| --> | ||
|
|
||
| ## Test Plan | ||
|
|
||
| <!-- | ||
| **Note:** *Not required until targeted at a release.* | ||
| 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 of 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). | ||
| --> | ||
|
|
||
| ## 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. | ||
| --> | ||
|
|
||
| ## Infrastructure Needed (optional) | ||
|
|
||
| <!-- | ||
| Use this section if you need things from the project/SIG. Examples include a | ||
| new subproject, repos requested, github details. Listing these here allows a | ||
| SIG to get the process for these resources started right away. | ||
| --> | ||
|
|
||
| ## Upgrade & Migration Strategy (optional) | ||
| 1. First Trigger CRD will be introduced. Trigger will be used as ref in EventListener alongwith | ||
| existing definition in EventListener Spec. Later on definition will be deprecated. | ||
| 2. Selector based EventListener will be implemented next. It will introduced along with existing implemention. | ||
| 3. Path based EventListener will be implemented along with existing implemention. | ||
| 4. Deprecating triggers section in EventListener. | ||
|
|
||
|
|
||
| <!-- | ||
| Use this section to detail wether 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. | ||
| --> |