:Add Risk and Mitigation to TEP000X

teps/000X-trigger-crd.md

@@ -126,9 +126,12 @@ demonstrate the interest in a TEP within the wider Tekton community.
 [experience reports]: https://github.com/golang/go/wiki/ExperienceReports
 -->
 Today, EventListener commonly are created for every namespace and handle TriggerBinding and
-TriggerTemplate in that same namespace. Creation of EventListener causes pod proliferation. For
-every namespace that requires handling of webhook, we need EventListener which in turns lead to
-this pod proliferation and causes excess resource consumption.
+TriggerTemplate in that same namespace. Creation of EventListener causes pod proliferation. For every 
+namespace that requires handling of webhook events like github, we need EventListener which in turns 
+lead to this pod proliferation and causes excess resource consumption. In multitenant scenario where
+projects are divided according to namespaces, we require EventListener for each namespaces. So for 
+100 of projects, we would need 100 of pods just for acting as sink for these webhook events like github.
+These pods in turn consume resources.
 
 ### Goals
 
@@ -153,9 +156,8 @@ This will be handled by operator or admin of the cluster.
 <!--
 List the requirements for this TEP.
 -->
-1. Add a new CRD Trigger which will be extracted from Trigger definition in EventListener Spec.
-2. Bind this Trigger CRD to EventListener.
-3. Ability to run Trigger resource in a different namespace from EventListener namespace.
+It must be possible for EventListener to function in Multitenant scenarios. A single EventListener 
+should be able to process events for triggertemplate resources in different namespaces.
 
 ## Proposal
 
@@ -229,15 +231,17 @@ Include as much detail as possible so that people can understand the "how" of
 the system.  The goal here is to make this feel real for users without getting
 bogged down.
 -->
-
-#### Trigger CRD Implmentation
-Trigger CRD will be implemented. Trigger CRD spec will contain serviceaccount, triggerbinding, 
-triggertemplate and interceptor. ServiceAccount will be optional. If not defined, ServiceAccount
-of EventListener will be used.
-
-#### EventListener Selector Implementation
-Selector based EventListener implementation will be introduced. All namespace matching the 
-boundnamespaces in EventListener will be served by EventListener.
+We have two type of users:
+1. End users who requires his event to be processed.
+2. Operator/admin who managed EventListener.
+#### Trigger Ref inside the EventListener
+Instead of defining Trigger inside EventListener, Trigger resource will be created by end user.
+Trigger will contain serviceaccount, triggerbinding, triggertemplate and interceptor.ServiceAccount 
+will be optional. If not defined, ServiceAccount of EventListener will be used.
+
+#### Specifying Namespaces where EventListener can serve
+Admin/Operator would give which namespaces EventListener can serve. In this way, EventListener can be used
+in Multitenant Scenarios.
 
 #### Path Base EventListener Implementation
 Path base EventListener will be implemented.
@@ -263,6 +267,12 @@ How will UX be reviewed and by whom?
 
 Consider including folks that also work outside the WGs or subproject.
 -->
+1. Security issue - Wide permission to EventListener. In this scenario EventListener
+will function in the same way as controller. It will be the responsibility of Operator
+or admin to manage that.
+2. Log: How will user access the EventListener log to debug their events.
+3. Resource Hog issue: A particular namespace or project could hog most of the Resources. Operator
+can handle this issue. This is similar to triggers controller or webhook.
 
 ### User Experience (optional)
 
@@ -327,6 +337,11 @@ What other approaches did you consider and why did you rule them out?  These do
 not need to be as detailed as the proposal, but should include enough
 information to express the idea and why it was not acceptable.
 -->
+1. Mode base EventListener where operator/admin specify scope of EventListener based on 
+that EventListener deployment is namespaced or clustered scope. If clustered, for every 
+EventListener, we have same deployment for every EventListener resource. Further discussion
+in this [doc](https://docs.google.com/document/d/1NX0ExhPad6ixTM8AdU0b6Vc3MVD5hQ_vIrOs9dIXq-I/edit).
+
 
 ## Infrastructure Needed (optional)