From 42a2482b55b5e238ab205b83252e174591cfa463 Mon Sep 17 00:00:00 2001 From: Piyush Garg Date: Mon, 2 Nov 2020 21:53:31 +0530 Subject: [PATCH] Add more details of design --- teps/0025-proxy-support.md | 85 ++++++++++++++++++++++++++++++-------- 1 file changed, 68 insertions(+), 17 deletions(-) diff --git a/teps/0025-proxy-support.md b/teps/0025-proxy-support.md index 2535f918a..cbfedc280 100644 --- a/teps/0025-proxy-support.md +++ b/teps/0025-proxy-support.md @@ -5,9 +5,9 @@ authors: - "@piyush-garg" - "@vdemeester" -creation-date: 2020-03-14 +creation-date: 2020-11-02 -last-updated: 2020-03-14 +last-updated: 2020-11-02 status: proposed @@ -20,6 +20,7 @@ status: proposed - [Motivation](#motivation) - [Goals](#goals) - [Non-Goals](#non-goals) +- [Requirements](#requirements) - [Proposal](#proposal) - [User Stories (optional)](#user-stories-optional) - [Notes/Constraints/Caveats (optional)](#notesconstraintscaveats-optional) @@ -44,8 +45,7 @@ can make use of it during execution. ## Motivation -This will enable users/organisations to enable network proxy settings for CI/CD using tekton if their -workload is expected to communicate to outside world through proxy. +Support users or organisations that require a network proxy settings for their workload to communicate to outside world, including CI/CD. ### Goals @@ -56,27 +56,30 @@ workload is expected to communicate to outside world through proxy. 1. Managing or maintaining proxy settings. +## Requirements + +1. User should be able to define proxy config for all workloads +2. User should be able to provide proxy config for specific taskrun/pipelinerun +3. Controllers should use proxy setting for communication + ## Proposal This proposal is to allow tektoncd/pipeline and tektoncd/triggers to have proxy support enabled / configurable to benefit users/organizations to use proxy feature to communicate to the outside world of the platform. -It can be configured to use proxy setting defined in the platform. - ### User Stories (optional) User should be able to define global proxy settings on the platform and tektoncd/pipeline and tektoncd/triggers act based on the proxy settings defined. -1. User should be able to define proxy config for all workloads -2. User should be able to provide proxy config for specific taskrun/pipelinerun -3. Controllers should use proxy setting for communication +1. User A has http proxy setup on cluster. +2. User B has http/https proxy ssetup on cluster along with certs. +3. User C wants to run only some specific workload only under proxy setup. ### Notes/Constraints/Caveats (optional) -1. If a user configures proxy settings for platform, should we provide a way to run some workloads without proxy settings. -2. Changes required for tektoncd/triggers (yet to explore) +1. Changes required for tektoncd/triggers (yet to explore) ### Risks and Mitigations @@ -84,7 +87,8 @@ None ### User Experience (optional) -There will be some spec changes for providing the proxy settings to pipelinrun/taskrun/pod level. +There will be some spec changes for providing the proxy settings to pipelinerun/taskrun/pod level. But there will be no +breaking changes and only additional spec config if user wants to leverage proxy setting. More details in design section. ### Performance (optional) @@ -92,16 +96,63 @@ None ## Design Details +Solution 1: + We can provide a standard configmap to define the global proxy settings. User can create a configmap with respective data to provide the proxy settings as configmap -Later, controller based on the data available in configmap, it should add the env variables related to -the global proxy setting at the pipelinrun/taskrun/pod spec. +``` +apiVersion: v1 +kind: ConfigMap +metadata: + name: proxy-config +data: + httpProxy: http://:@: + httpsProxy: http://:@: + noProxy: example.com +``` + +We should provide a way to specify env at taskrun/pipelinerun level, may be as part of spec, and then controller based on this +configmap add those env to the taskrun/pipeline run and further propagate to pod. Use can run a specific workload also with proxy +settings by specifying the envs. + +User should patch the controller/webhook with these env manually or using some tooling like helm. + +Operator should append these env to the controller/webhook during installation based on the configmap available. + +Solution 2: + +We can provide a field to specify env in podtemplate, also default podtemplate should have env field.. So user can define the proxy env in the +default podtemplate and controller based on the default podtemplate should add these to the pipelinerun/taskrun during execution. + +``` +apiVersion: v1 +kind: ConfigMap +metadata: + name: config-defaults +data: + default-service-account: "tekton" + default-timeout-minutes: "20" + default-pod-template: | + envs: + - name: key + value: value +``` + +Here we dont need to specify field at spec level, rather than a field in podtemplate for env. + +User should patch the controller/webhook with these env manually or using some tooling like helm. + +Operator should append these env to the controller/webhook during installation based on the default pod template env available. + + +Solution 3: -We should also provide a way to specify env variable to the pipelinerun/taskrun spec so that -a specific workload should also be run with proxy settings if a user dont want to run the all workloads of environment. +User define the proxy env by manually editing the controller/webhook deployment and then while scheduling taskrun/pipelienrun, using its own spec +to get then proxy related envs and then append it to the taskrun/pipelinrun. We should provide a way to specify env to te tasrun/pipelinerun spec either +through spec.envs field or podtemplate field. -Issues to be resolved +Related issues. 1. [Proxy support in workloads](https://github.com/tektoncd/pipeline/issues/3090) 2. [Way to set env for workloads](https://github.com/tektoncd/pipeline/issues/1606)