diff --git a/keps/sig-scheduling/20200114-multi-scheduling-profiles.md b/keps/sig-scheduling/20200114-multi-scheduling-profiles.md index f10751fc89dd..86a339da61d4 100644 --- a/keps/sig-scheduling/20200114-multi-scheduling-profiles.md +++ b/keps/sig-scheduling/20200114-multi-scheduling-profiles.md @@ -41,8 +41,6 @@ see-also: - [Risks and Mitigations](#risks-and-mitigations) - [Design Details](#design-details) - [Test Plan](#test-plan) - - [For Alpha](#for-alpha) - - [For Beta](#for-beta) - [Graduation Criteria](#graduation-criteria) - [Alpha (v1.18):](#alpha-v118) - [Implementation History](#implementation-history) @@ -243,6 +241,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,11 +261,10 @@ 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: @@ -271,12 +272,13 @@ profile, in which: - 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