--- status: proposed title: Custom Configuration creation-date: '2021-08-25' last-updated: '2021-08-25' authors: - '@sbwsg' - '@jerop' see-also: - TEP-0033 --- # TEP-0080: Custom Configuration <!-- toc --> - [Summary](#summary) - [Motivation](#motivation) - [Gradual Migration](#gradual-migration) - [Flexible Configuration](#flexible-configuration) - [Thorough Testing](#thorough-testing) - [Use Cases](#use-cases) - [Gradual Migration](#gradual-migration-1) - [Flexible Configuration](#flexible-configuration-1) - [Thorough Testing](#thorough-testing-1) - [Requirements](#requirements) - [Proposal](#proposal) - [Notes/Caveats (optional)](#notescaveats-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) - [Design Evaluation](#design-evaluation) - [Drawbacks](#drawbacks) - [Alternatives](#alternatives) - [Infrastructure Needed (optional)](#infrastructure-needed-optional) - [Upgrade &amp; Migration Strategy (optional)](#upgrade--migration-strategy-optional) - [Implementation Pull request(s)](#implementation-pull-request-s) - [References](#references) <!-- /toc --> ## Summary This TEP proposes support for overriding Tekton Pipelines' configuration on a per-namespace basis in order to: - improve flexibility for organizations gradually migrating their teams during Tekton's infrequent (but potentially disruptive) behavioural changes - allow platforms and organizations to apply finer-grained configurations, such as individualized RBAC on a per-tenant basis - improve a key portion of our own open source testing strategy by allowing configuration changes to be exercised in isolated namespaces rather than entirely separate clusters ## Motivation #### Gradual Migration Today, Tekton Pipelines only supports binary on/off when we introduce behavioural changes. This forces organizations that host multiple teams in a single cluster to migrate everybody to new behaviours all at once. It also limits the ability of individual teams to test their own Pipelines and Tasks with backwards incompatible changes, since doing so would require their own cluster with the behavioural flag flipped. Establishing a process for Tekton Pipelines to make these infrequent behavioural changes in a way that supports gradual organizational rollout should reduce operator burden, allow teams to individually migrate themselves and provide clearer insights during such a transition. #### Flexible Configuration Overriding Tekton Pipelines' configuration on a per-namespace basis would be useful in other configuration beyond behavioral changes. For example, overriding the default service account applied to runs in a specific namespace would allow for finer-grained RBAC in multi-tenant setups. #### Thorough Testing By allowing Tekton Pipelines' configuration to be overridden per-namespace, we can ramp up testing of non-default configuration much more easily. Instead of deploying entire clusters to flip one flag to test that functionality, we'd instead be able to tweak configuration in a namespace and run a test there. ### Use Cases <!-- Describe the concrete improvement specific groups of users will see if the Motivations in this doc result in a fix or feature. Consider both the user's role (are they a Task author? Catalog Task user? Cluster Admin? etc...) and experience (what workflows or actions are enhanced if this problem is solved?). --> #### Gradual Migration As an operator, I need to gradually migrate functionality by enabling users and teams to opt in to new functionality over time before the migration is complete. As a user, I need to migrate to and use new functionality in my namespace before the feature is enabled across the cluster. #### Flexible Configuration As an operator, I need to apply customized configuration for a given namespace in my cluster such as individualized RBAC on a per-tenant basis. #### Thorough Testing As a contributor, I need to test my behavioral changes to ensure that they work as expected in different configurations. ### Requirements <!-- Describe constraints on the solution that must be met. Examples might include performance characteristics that must be met, specific edge cases that must be handled, or user scenarios that will be affected and must be accomodated. --> - Operator can allow for configuration to be defined on per-namespace basis - User can specify and use a customized configuration for a given 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. --> ### Notes/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) <!-- 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. 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". --> ## 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). --> ## Design Evaluation <!-- How does this proposal affect the reusability, simplicity, flexibility and conformance of Tekton, as described in [design principles](https://github.com/tektoncd/community/blob/master/design-principles.md) --> ## Drawbacks <!-- Why should this TEP _not_ be implemented? --> ## Alternatives ### Allow Behavioural Flags to be overridden on a per-PipelineRun / TaskRun basis Reducing the scope considerably to only the behavioural flags that initially inspired this TEP would allow a finer grained approach: allow individuals to set behavioural flag overrides on a per-PipelineRun or per-TaskRun basis. #### Pros * Reduced scope for this TEP. #### Cons * Not as broadly applicable to other scenarios. * Backwards-incompatible changes should essentially never happen once we release v1 so the long-term utility would drop off dramatically. * ## 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) <!-- 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. --> ## Implementation Pull request(s) <!-- Once the TEP is ready to be marked as implemented, list down all the Github Pull-request(s) merged. 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 <!-- 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 Pipelines Issue #4190](https://github.com/tektoncd/pipeline/issues/4190) - [TEP-0033: Tekton Feature Gates](https://github.com/tektoncd/community/blob/main/teps/0033-tekton-feature-gates.md#existing-alpha-field-flags)