Remove E2E from Test Plan and clarify shared cache

Signed-off-by: Aldo Culquicondor <[email protected]>

Author: alculquicondor

keps/sig-scheduling/20200114-multi-scheduling-profiles.md

@@ -243,6 +243,10 @@ the scheduler queue.
 framework instance from the registry corresponding to the specified scheduler
 name.
 
+Note that all framework instances will make use of the same shared cache
+(for nodes and pods), from which a snapshot is taken for each scheduling cycle.
+This is the main advantage over running multiple schedulers in a cluster.
+
 ### Risks and Mitigations
 
 Operators could introduce profiles that disable scheduling features exposed in
@@ -259,24 +263,24 @@ the scheduler documentation.
 
 The following tests need to be in place:
 
-#### For Alpha
-
-- **Unit Tests**: For Component Config API conversion, validation and defaults, core scheduler and
-scheduler instantiation. Current tests that use a default scheduler (or default framework) should
-continue passing with no configuration changes.
+- **Unit Tests**:
+    - Component Config API conversion, validation and defaults
+    - Core scheduler implementation. Current tests that use a default scheduler
+    (or default framework) should continue passing with no configuration changes.
 - **Integration tests**: Current tests with a default scheduler should continue passing with no
 configuration changes. We need new tests in `test/integration/scheduler` exercising more than one
 profile, in which:
     - Each profile would favor specific nodes, so that we can verify assignment.
     - Pods get binding events for the selected scheduler name.
     - Pods that don't specify a scheduler name continue to be scheduled by the default profile.
 
+*Note on E2E tests*
 
-#### For Beta
-
-- **E2E tests**: A representative case from Integration tests will be replicated as E2E,
-to live in `test/e2e/scheduling`. To exercise the custom configuration, we need to set up a new
-job in `k8s.io/test-infra/config/jobs/kubernetes/sig-scheduling`.
+Due to the proposed architecture, where a single kube-scheduler binary runs all the profiles, E2E
+tests wouldn't increase the coverage of this feature over unit and integration tests.
+Additionally, profiles can only be provided statically during cluster creation with our current
+test infra. This implies that an independent job would be needed for each scheduler configuration.
+But, as stated in our goals, this KEP doesn't introduce new default profiles.
 
 ### Graduation Criteria