Add more details of design

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,52 +56,103 @@ 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
 
 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)
 
 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://<username>:<pswd>@<ip>:<port>
+  httpsProxy: http://<username>:<pswd>@<ip>:<port>
+  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)