From 036949842b13e921cc1f89d98bdf72c219dd1238 Mon Sep 17 00:00:00 2001 From: Quan Zhang Date: Fri, 3 Mar 2023 18:37:13 -0500 Subject: [PATCH] [TEP-0133] Configure Default Resolver This commit adds a new TEP: Configure Default Resolver. This commit adds proposal and implementation details to introduce a new field `default-resolver-type` in the ConfigMap to configure the default resolver type in Tekton. The design fulfills the requirement of [feature request #5907][#5907] /kind tep [#5907]: https://github.com/tektoncd/pipeline/issues/5907 --- teps/0133-configure-default-resolver.md | 164 ++++++++++++++++++++++++ teps/README.md | 1 + 2 files changed, 165 insertions(+) create mode 100644 teps/0133-configure-default-resolver.md diff --git a/teps/0133-configure-default-resolver.md b/teps/0133-configure-default-resolver.md new file mode 100644 index 000000000..3f5d1fbe5 --- /dev/null +++ b/teps/0133-configure-default-resolver.md @@ -0,0 +1,164 @@ +--- +status: implementable +title: Configure Default Resolver +creation-date: '2023-03-03' +last-updated: '2023-03-03' +authors: +- '@QuanZhang-William' +- '@vdemeester' +collaborators: [] +--- + +# TEP-0133: Configure Default Resolver + +- [Summary](#summary) +- [Motivation](#motivation) + - [Goals](#goals) + - [Use Cases](#use-cases) + - [Custome Resolver](#custom-resolver) + - [Common Remote Resource Storage](#common-remote-resource-storage) +- [Proposal](#proposal) +- [Design Details](#design-details) + - [Populate Default Resolver](#populate-default-resolver) + - [Validation Webhook](#validation-webhook) +- [Design Evaluation](#design-evaluation) + - [Simplicity](#simplicity) + - [Flexibility](#flexibility) + - [Reusability](#reusability) +- [Alternatives](#alternatives) +- [References](#references) + + +## Summary +This TEP proposes to support configurable default `Resolver` type to improve the simplicity of *Remote Resolution*. This TEP builds on prior work [TEP-0060]. + +## Motivation +Today, Tekton users must explicitly specify the `Resolver` type to use Remote Resolution, which brings verbosity when authoring the input yaml file. + +### Goals +- Allow cluster operators to configure a default `Resolver` type when using Tekton Pipelines . +- The default `Resolver` can either be a built-in type (`hub`, `git`, `cluster`, and `bundle`) or a [Custom Resolver]. + +### Use Cases +#### Custom Resolver +As a company cluster operator, I may have my own [Custom Resolver] which is used by most of the cluster users when resolving remote resources. I may want to simplify the user experience with such default values at the authoring time. + +#### Common Remote Resource Storage +As a company cluster operator, all of the company's `Tasks` and `Pipelines` are stored in the same GitHub repo. I may not want to enforce the company users to specify the `Resolver` type for every `TaskRun` and `PipelineRun` (see the [issue #5907]). + +## Proposal +To support the configurable default `Resolver` type, we propose to introduce a new field `default-resolver-type` in the [config-defaults.yaml][config-defaults]. + +With the `default-resolver-type` field configured, authors can create `TaskRun` and `PipelineRun` without setting the `resolver` field in the yaml input. + +For example: + +```yaml +apiVersion: tekton.dev/v1beta1 +kind: TaskRun +metadata: + name: demo-task-run +spec: + taskRef: + #resolver: git + params: + - name: url + value: https://github.com/tektoncd/catalog.git + - name: revision + value: main + - name: pathInRepo + value: task/golang-build/0.1/golang-build.yaml +``` + +Here is another example where a `Pipeline` tries to resolve a remote `PipelineTask`: + +```yaml +apiVersion: tekton.dev/v1beta1 +kind: Pipeline +metadata: + name: demo-pipeline +spec: + tasks: + - name: post-message + taskRef: + #resolver: hub + params: + - name: kind + value: task + - name: name + value: github-add-comment + - name: version + value: "0.7" + params: + ... +``` + +If the `default-resolver-type` field is **not** configured, the Tekton Pipeline project should behave the same way as before (i.e. the *validation webhook* should fail with a missing `resolver` field). + +To keep this new feature as "opt-in", we propose **not** to specify a default value to this field. + +``` yaml + # Setting this flag to a resolver type as the default resolver + default-resolver-type: "" +``` + +The resource author can overwrite the default `Resolver` by explicitly setting it in the yaml input. + +## Design Details +### Populate Default Resolver +We propose to populate the default value in the current `SetDefault` function of `TaskRunSpec` and `PipelineSpec`. + +Taking `TaskRunSpec` as an example: + +```go +// SetDefaults implements apis.Defaultable +func (trs *TaskRunSpec) SetDefaults(ctx context.Context) { + cfg := config.FromContextOrDefaults(ctx) + if trs.TaskRef != nil { + if trs.TaskRef.Kind == "" { + trs.TaskRef.Kind = NamespacedTaskKind + } + if trs.TaskRef.Name == "" && trs.TaskRef.Resolver == "" { + trs.TaskRef.Resolver = ResolverName(cfg.Defaults.DefaultResolverType) + } + } +} +``` + +### Validation Webhook +If the `resolver` is neither explicitly provided nor set by default, the *validation webhook* should fail the execution. + +The current validation webhook logic already covers such a scenario given the default value population happens beforehand in the *mutation webhook* phase. + +To support defaulting to `Custom Resolver` types, the validation webhook should not check the value specified in the `default-resolver-type` field. + +## Design Evaluation +### Simplicity +This design simplifies the user experience at resource authoring time where authors can skip specifying the `resolver` field when applicable. + +This design also provides a simple solution to cluster operators to configure the default `Resolver` type when necessary. + +### Flexibility +This design exhibits flexibility by allowing to default to `Custom Resolver` based on each team/company's needs + +### Reusability +This design inhibits the reusability at the authoring time since we cannot guarantee that a `TaskRun` that works in cluster A can necessarily work in cluster B when the default `Resolvers` are configured differently. + +However, authors can overwrite the default `resolver` by explicitly setting the field which mitigates this drawback. In addition, we should provide clear documentation highlighting this reusability risk when a resource needs to be applied across clusters. + +## Alternatives +Instead of setting the default `Resolver` in the [config-defaults.yaml][config-defaults], we could put the configuration in the [resolver feature flag]. + +However, the [resolver feature flag] resides in the `tekton-pipelines-resolver` namespace instead of the `tekton-pipelines` namespace. This alternative introduces an extra dependency to the `tekton-pipelines-resolver` namespace for *Tekton Webhooks and Controllers* while bringing no extra benefit. + +We can revisit this alternative if we decide to merge the `tekton-pipelines-resolver` back to the `tekton-pipelines` namespace in the future. + +## References +- [TEP-0060: Remote Resolution][TEP-0060] + +[TEP-0060]: https://github.com/tektoncd/community/blob/main/teps/0060-remote-resource-resolution.md +[custom Resolver]: https://github.com/tektoncd/pipeline/tree/main/docs/resolver-template +[issue #5907]: https://github.com/tektoncd/pipeline/issues/5907 +[config-defaults]: https://github.com/tektoncd/pipeline/blob/main/config/config-defaults.yaml +[resolver feature flag]: https://github.com/tektoncd/pipeline/blob/main/config/resolvers/config-feature-flags.yaml +[git resolver ConfigMap]: https://github.com/tektoncd/pipeline/blob/main/config/resolvers/git-resolver-config.yaml diff --git a/teps/README.md b/teps/README.md index 4b62dbc8f..474eff8e4 100644 --- a/teps/README.md +++ b/teps/README.md @@ -119,3 +119,4 @@ This is the complete list of Tekton TEPs: |[TEP-0127](0127-larger-results-via-sidecar-logs.md) | Larger Results via Sidecar Logs | implemented | 2022-12-15 | |[TEP-0128](0128-scheduled-runs.md) | Scheduled Runs | implementable | 2022-12-20 | |[TEP-0129](0129-multiple-tekton-instances-per-cluster.md) | Multiple Tekton instances per cluster | proposed | 2023-01-11 | +|[TEP-0133](0133-configure-default-resolver.md) | Configure Default Resolver | implementable | 2023-03-03 |