@@ -6,25 +6,25 @@ To get started with this template:
6
6
- [x] **Pick a hosting SIG.**
7
7
Make sure that the problem space is something the SIG is interested in taking
8
8
up. KEPs should not be checked in without a sponsoring SIG.
9
- - [ ] **Create an issue in kubernetes/enhancements**
9
+ - [x ] **Create an issue in kubernetes/enhancements**
10
10
When filing an enhancement tracking issue, please make sure to complete all
11
11
fields in that template. One of the fields asks for a link to the KEP. You
12
12
can leave that blank until this KEP is filed, and then go back to the
13
13
enhancement and add the link.
14
- - [ ] **Make a copy of this template directory.**
14
+ - [x ] **Make a copy of this template directory.**
15
15
Copy this template into the owning SIG's directory and name it
16
16
`NNNN-short-descriptive-title`, where `NNNN` is the issue number (with no
17
17
leading-zero padding) assigned to your enhancement above.
18
- - [ ] **Fill out as much of the kep.yaml file as you can.**
18
+ - [x ] **Fill out as much of the kep.yaml file as you can.**
19
19
At minimum, you should fill in the "Title", "Authors", "Owning-sig",
20
20
"Status", and date-related fields.
21
- - [ ] **Fill out this file as best you can.**
21
+ - [x ] **Fill out this file as best you can.**
22
22
At minimum, you should fill in the "Summary" and "Motivation" sections.
23
23
These should be easy if you've preflighted the idea of the KEP with the
24
24
appropriate SIG(s).
25
- - [ ] **Create a PR for this KEP.**
25
+ - [x ] **Create a PR for this KEP.**
26
26
Assign it to people in the SIG who are sponsoring this process.
27
- - [ ] **Merge early and iterate.**
27
+ - [x ] **Merge early and iterate.**
28
28
Avoid getting hung up on specific details and instead aim to get the goals of
29
29
the KEP clarified and merged quickly. The best way to do this is to just
30
30
start with the high-level sections and fill out details incrementally in
@@ -104,8 +104,8 @@ Items marked with (R) are required *prior to targeting to a milestone / release*
104
104
- [x] (R) Production readiness review completed
105
105
- [x] Production readiness review approved
106
106
- [x] "Implementation History" section is up-to-date for milestone
107
- - [ ] User-facing documentation has been created in [ kubernetes/website] , for publication to [ kubernetes.io]
108
- - [ ] Supporting documentation—e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes
107
+ - [x ] User-facing documentation has been created in [ kubernetes/website] , for publication to [ kubernetes.io]
108
+ - [x ] Supporting documentation—e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes
109
109
110
110
[ kubernetes.io ] : https://kubernetes.io/
111
111
[ kubernetes/enhancements ] : https://git.k8s.io/enhancements
@@ -225,6 +225,9 @@ period is honoured. Pods terminated this way are considered a failure and the
225
225
controller does not count terminated Pods towards completions. This behaviour
226
226
is similar to decreasing the Job's parallelism to zero.
227
227
228
+ Completed pods before suspension will count towards completion after the job is unsuspended.
229
+ For example, for jobs with ` completionMode: Indexed ` ; successfully completed indexes will not run again.
230
+
228
231
Similar to existing [ JobConditionType] ( https://github.com/kubernetes/kubernetes/blob/c98f6bf30890f2c5826067ae50cfc36958106e68/staging/src/k8s.io/api/batch/v1/types.go#L167 ) s
229
232
"Complete" and "Failed", we propose adding a new condition type called
230
233
"Suspended" as a part of the Job's status as follows:
@@ -291,67 +294,12 @@ Unit, integration, and end-to-end tests will be added to test that:
291
294
* We're confident that no further semantical changes will be needed to achieve the goals of the KEP
292
295
* All known functional bugs have been fixed
293
296
294
- <!--
295
- **Note:** *Not required until targeted at a release.*
296
-
297
- Define graduation milestones.
298
-
299
- These may be defined in terms of API maturity, or as something else. The KEP
300
- should keep this high-level with a focus on what signals will be looked at to
301
- determine graduation.
302
-
303
- Consider the following in developing the graduation criteria for this enhancement:
304
- - [Maturity levels (`alpha`, `beta`, `stable`)][maturity-levels]
305
- - [Deprecation policy][deprecation-policy]
306
-
307
- Clearly define what graduation means by either linking to the [API doc
308
- definition](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-versioning)
309
- or by redefining what graduation means.
310
-
311
- In general we try to use the same stages (alpha, beta, GA), regardless of how the
312
- functionality is accessed.
313
-
314
- [maturity-levels]: https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions
315
- [deprecation-policy]: https://kubernetes.io/docs/reference/using-api/deprecation-policy/
316
-
317
- Below are some examples to consider, in addition to the aforementioned [maturity levels][maturity-levels].
318
-
319
- #### Alpha -> Beta Graduation
320
-
321
- - Gather feedback from developers and surveys
322
- - Complete features A, B, C
323
- - Tests are in Testgrid and linked in KEP
324
-
325
- #### Beta -> GA Graduation
326
-
327
- - N examples of real-world usage
328
- - N installs
329
- - More rigorous forms of testing—e.g., downgrade tests and scalability tests
330
- - Allowing time for feedback
331
-
332
- **Note:** Generally we also wait at least two releases between beta and
333
- GA/stable, because there's no opportunity for user feedback, or even bug reports,
334
- in back-to-back releases.
335
-
336
- #### Removing a Deprecated Flag
337
-
338
- - Announce deprecation and support policy of the existing flag
339
- - Two versions passed since introducing the functionality that deprecates the flag (to address version skew)
340
- - Address feedback on usage/changed behavior, provided on GitHub issues
341
- - Deprecate the flag
342
-
343
- **For non-optional features moving to GA, the graduation criteria must include
344
- [conformance tests].**
345
-
346
- [conformance tests]: https://git.k8s.io/community/contributors/devel/sig-architecture/conformance-tests.md
347
- -->
348
-
349
297
### Upgrade / Downgrade Strategy
350
298
351
299
Upgrading from 1.20 and below will not change the behaviour of how Jobs work.
352
300
353
301
To make use of this feature, the ` SuspendJob ` feature gate must be explicitly
354
- enabled on the API server and the controller manager and the ` suspend ` field
302
+ enabled on the api- server and kube- controller- manager and the ` suspend ` field
355
303
must be explicitly set in the Job spec.
356
304
357
305
### Version Skew Strategy
@@ -414,10 +362,7 @@ _This section must be completed when targeting beta graduation to a release._
414
362
While the above list isn't exhaustive, they're signals in favour of rollbacks.
415
363
416
364
* ** Were upgrade and rollback tested? Was the upgrade->downgrade->upgrade path
417
- tested?** <!-- I'll answer this after implementation.
418
- Describe manual testing that was done and the outcomes.
419
- Longer term, we may want to require automated upgrade/rollback tests, but we
420
- are missing a bunch of machinery and tooling and can't do that now. -->
365
+ tested? yes manually tested successfully.
421
366
422
367
* ** Is the rollout accompanied by any deprecations and/or removals of features,
423
368
APIs, fields of API types, flags, etc.?** No.
@@ -431,6 +376,14 @@ _This section must be completed when targeting beta graduation to a release._
431
376
Job can also be used to determine whether a Job is using the feature (look
432
377
for a condition of type "Suspended").
433
378
379
+ * ** How can someone using this feature know that it is working for their instance?**
380
+ - [x] Events
381
+ - Event Reason: Suspended
382
+ - The message includes the job name.
383
+ - [x] API .status
384
+ - Condition name: Suspended
385
+ - Other field:
386
+
434
387
* ** What are the SLIs (Service Level Indicators) an operator can use to
435
388
determine the health of the service?**
436
389
- [x] Metrics
@@ -532,6 +485,7 @@ _This section must be completed when targeting beta graduation to a release._
532
485
2021-02-01: Initial KEP merged, alpha targeted for 1.21
533
486
2021-03-08: Implementation merged in 1.21 with feature gate disabled by default
534
487
2021-04-22: KEP updated for beta graduation in 1.22
488
+ 2022-01-18: KEP updated for GA graduation in 1.24
535
489
536
490
## Drawbacks
537
491
0 commit comments