Skip to content

Commit

Permalink
Remove AlgorithmSource and move E2E test to Beta requirements.
Browse files Browse the repository at this point in the history
Signed-off-by: Aldo Culquicondor <[email protected]>
  • Loading branch information
alculquicondor committed Jan 24, 2020
1 parent 26e9d50 commit 180db85
Showing 1 changed file with 34 additions and 12 deletions.
46 changes: 34 additions & 12 deletions keps/sig-scheduling/20200114-multi-scheduling-profiles.md
Original file line number Diff line number Diff line change
Expand Up @@ -41,6 +41,8 @@ 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)
Expand Down Expand Up @@ -135,6 +137,7 @@ looks like the following:
type KubeSchedulerConfiguration struct {
...
SchedulerName string
AlgorithmSource SchedulerAlgorithmSource
HardPodAffinitySymmetricWeight
Plugins *Plugins
PluginConfig []PluginConfig
Expand All @@ -157,14 +160,21 @@ type KubeSchedulerProfile struct {
}
```

Note that we remove `AlgorithmSource` from the new API. It's functionality becomes redundant to
what can be configured with `Plugins` and `PluginConfig`.

##### Conversion between API versions

During conversion from `v1alpha1` to `v1alpha2`, we will copy all the necessary
parameters from KubeSchedulerConfiguration into one item in the `Profiles` list.
During conversion of `kubescheduler.config.k8s.io` from `v1alpha1` to `v1alpha2`, we will copy all
the necessary parameters from KubeSchedulerConfiguration into one item in the `Profiles` list.

In particular, configurations done by using `AlgorithmSource` will produce different values for
`Plugins` and `PluginConfig`.
This is similar to what we already do internally in [`legacy_registry.go`](
https://github.com/kubernetes/kubernetes/blob/fb66e807cd317254e5c7bf134186ddbfba757ef4/pkg/scheduler/framework/plugins/legacy_registry.go#L149)

`HardPodAffinitySymmetricWeight` would be moved to be a `PluginConfig.Arg` in
the `PluginConfig` slice for the plugin `InterPodAffinity` as
`HardPodAffinityWeight`.
the `PluginConfig` slice for the plugin `InterPodAffinity` as `HardPodAffinityWeight`.

##### Defaults

Expand Down Expand Up @@ -196,14 +206,15 @@ configurations are strictly the same.

##### CLI flags binding

Note that, if component config is used, deprecated flags are currently ignored,
which includes `scheduler-name` and `hard-pod-affinity-symmetric-weight`. This
implies that we only have to worry about these flags in relationship with the
default profile.
Note that, if component config is used, deprecated flags are currently ignored, which includes
`scheduler-name`, `algorithm-provider` and `hard-pod-affinity-symmetric-weight`. This implies
that we only have to worry about these flags in relationship with the default profile.

Thus, if component config is not used, we will preserve the behavior of the
flags as follows:
- `scheduler-name` will be bound to its counterpart in the default profile.
- `algorithm-provider` will produce different `Plugins` configurations. For examples, it will
produce an empty configuration for `default-scheduler`.
- `hard-pod-affinity-symmetric-weight` will be bound to a new deprecated option
that will be processed into a `pluginConfig` slice of the default profile,
like follows:
Expand Down Expand Up @@ -248,6 +259,8 @@ 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.
Expand All @@ -257,23 +270,32 @@ 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.


#### For Beta

- **E2E tests**: A representative case from Integration tests will be replicated as E2E,
to live in `test/e2e/scheduling`.
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`.

### Graduation Criteria

#### Alpha (v1.18):

These are the required changes:

- [ ] New `kubescheduler.config.k8s.io/v1alpha2` API, with conversion from
`kubescheduler.config.k8s.io/v1alpha1`, validation and defaults.
- [ ] New feature gate.
- [ ] New `kubescheduler.config.k8s.io/v1alpha2` API.
- [ ] Conversion from `kubescheduler.config.k8s.io/v1alpha1`
- [ ] Validation.
- [ ] Defaults.
- [ ] Scheduler can run more than one framework:
- [ ] Scheduler adds unscheduled pods to the pending queue for more than one name.
- [ ] Scheduler uses a framework using the scheduler name specified by the pod.
- [ ] Tests from [Test Plan](#test-plan).

Note that we don't require a feature gate as users already have to opt-in by using
`kubescheduler.config.k8s.io/v1alpha2` instead of the previous version.

## Implementation History

- 2020-01-14: Initial KEP sent out for review, including Summary, Motivation
Expand Down

0 comments on commit 180db85

Please sign in to comment.