@@ -26,9 +26,9 @@ Items marked with (R) are required *prior to targeting to a milestone / release*
26
26
- [ ] (R) KEP approvers have approved the KEP status as ` implementable `
27
27
- [x] (R) Design details are appropriately documented
28
28
- [ ] (R) Test plan is in place, giving consideration to SIG Architecture and SIG Testing input
29
- - [ ] (R) Graduation criteria is in place
29
+ - [x ] (R) Graduation criteria is in place
30
30
- [ ] (R) Production readiness review completed
31
- - [ ] Production readiness review approved
31
+ - [ ] (R) Production readiness review approved
32
32
- [ ] "Implementation History" section is up-to-date for milestone
33
33
- [ ] User-facing documentation has been created in [ kubernetes/website] , for publication to [ kubernetes.io]
34
34
- [ ] Supporting documentation—e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes
@@ -146,6 +146,19 @@ _This section must be completed when targeting alpha to a release._
146
146
- Feature gate name: PreferNominatedNode
147
147
- Components depending on the feature gate: kube-scheduler
148
148
149
+ * ** Does enabling the feature change any default behavior?**
150
+ Yes. The pod with the nominated node set will be evaluated first in any scheduling cycle,
151
+ this is only the default process logic that is handled by scheduler, end-user will not
152
+ and need not aware of any difference.
153
+
154
+ * ** Can the feature be disabled once it has been enabled (i.e. can we roll back
155
+ the enablement)?**
156
+ Yes. This could be opt-out by the feature gate, once switch off, it will fall back
157
+ to original behavior.
158
+
159
+ * ** What happens if we reenable the feature if it was previously rolled back?**
160
+ Nothing needs to be aware of for the end-user.
161
+
149
162
* ** Are there any tests for feature enablement/disablement?**
150
163
unittest will cover this.
151
164
0 commit comments