Add more details with pros/cons

teps/0031-proxy-support.md → teps/0033-proxy-support.md

@@ -13,7 +13,7 @@ status: proposed
 
 ---
 
-# TEP-0031: Proxy Support
+# TEP-0033: Proxy Support
 
 <!-- toc -->
 - [Summary](#summary)
@@ -170,13 +170,20 @@ data:
 ```
 
 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 
+configmap add those env to the taskrun/pipelinerun 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.
 
+Pros:
+1. Configmap should be more user-friendy to user.
+
+Cons:
+1. New way to define envs.
+2. More work/code in controller to do.
+
 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
@@ -202,12 +209,24 @@ User should patch the controller/webhook with these env manually or using some t
 
 Operator should append these env to the controller/webhook during installation based on the default pod template env available.
 
+Pros:
+1. It extends the current flow to define pod specific things.
+
+Cons:
+1. Less work/code in controller to do. Most of the logic is there.
+
 Solution 3:
 
 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
+to get then proxy related envs and then append it to the taskrun/pipelinerun. We should provide a way to specify env tho te taskrun/pipelinerun spec either
 through spec.envs field or podtemplate field.
 
+Pros:
+1. Nothing extra needs to be done. Just editing the controller spec is good.
+
+Cons:
+1. Evaluating its own spec may not be the right way to do thing.
+
 Related issues.
 
 1. [Proxy support in workloads](https://github.com/tektoncd/pipeline/issues/3090)

teps/README.md

@@ -145,3 +145,4 @@ This is the complete list of Tekton teps:
 |[TEP-0030](0030-workspace-paths.md) | workspace-paths | proposed | 2020-10-18 |
 |[TEP-0031](0031-tekton-bundles-cli.md) | tekton-bundles-cli | proposed | 2020-11-18 |
 |[TEP-0032](0032-tekton-notifications.md) | Tekton Notifications | proposed | 2020-11-18 |
+|[TEP-0033](0033-proxy-support.md) | proxy-support | proposed | 2020-11-02 |