Add more details for design

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

@@ -13,7 +13,7 @@ status: proposed
 
 ---
 
-# TEP-0025: Proxy Support
+# TEP-0031: Proxy Support
 
 <!-- toc -->
 - [Summary](#summary)
@@ -28,6 +28,7 @@ status: proposed
   - [User Experience (optional)](#user-experience-optional)
   - [Performance (optional)](#performance-optional)
 - [Design Details](#design-details)
+  - [Proposed Solutions](#proposed-solutions)
 - [Test Plan](#test-plan)
 - [Drawbacks](#drawbacks)
 - [Alternatives](#alternatives)
@@ -44,8 +45,8 @@ Tekton should provide a way to use network proxy settings defined for the platfo
 can make use of it during execution.
 
 The proposal is designed considering the way proxy settings at the container level is used. It just uses the
-container env spec which can be specified using taskrun/pipelinrun and leverage that. It abstracts the way to
-specify env for pods/containers to user.
+container env spec which can be specified using taskrun/pipelinerun and leverage that. It abstracts the way to
+specify env for pods/containers to the user.
 
 This proposal covers the proxy environment settings for following components:
 
@@ -83,8 +84,8 @@ User should be able to define global proxy settings on the platform and tektoncd
 and tektoncd/triggers act based on the proxy settings defined.
 
 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.
+2. User B has http/https proxy setup on cluster along with certs.
+3. User C wants to run only some specific workload under proxy setup.
 
 ### Notes/Constraints/Caveats (optional)
 
@@ -108,6 +109,50 @@ None
 
 ## Design Details
 
+The basic idea behind the design is to propogate proxy env varibales to all the containers of pods created by controllers.
+There should be a way to define proxy environment variable which controller will read and add to the spec of all containers.
+User should be able to define these env at platform level, pipelinerun level and taskrun level.
+
+The basic flow will be
+
+1. User should be able to define env at the platform level, taskrun level and pipelinerun level. An example of taskrun look like
+
+```
+apiVersion: tekton.dev/v1alpha1
+kind: TaskRun
+metadata:
+  name: read-repo
+spec:
+  taskRef:
+    name: read-task
+  env:
+  - name: "FOO"
+    value: "bar"
+```
+
+2. The controller while scheduling the pod, make sure to propogate these env to all the containers.
+
+```
+apiVersion: v1
+kind: Pod
+metadata:
+  name: read-repo-taskrun
+spec:
+  containers:
+  - name: prepare
+    image: docker.io/alpine@sha256:203ee936961c0f491f72ce9d3c3c67d9440cdb1d61b9783cf340baa09308ffc1
+    env:
+    - name: "FOO"
+      value: "bar"
+```
+
+User can specify a global level envs which can propagate to all the workloads. Also the global envs can be overidden
+at pipelinerun/taskrun level.
+
+### Proposed Solutions
+
+Here are the some solutions that can be a way to provide proxy support.
+
 Solution 1: 
 
 We can provide a standard configmap to define the global proxy settings. User can create a configmap with respective data