github/kubernetes
1
0
Fork 0
mirror of https://github.com/k3s-io/kubernetes.git synced 2025-07-23 19:56:01 +00:00
Code Issues Projects Releases Wiki Activity

Merge pull request #30208 from Crazykev/remove-duplicate-words

Browse Source 
Automatic merge from submit-queue

remove duplicate words in indexed-job


Signed-off-by: Crazykev <crazykev@zju.edu.cn>

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.kubernetes.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.kubernetes.io/reviews/kubernetes/kubernetes/30208)
<!-- Reviewable:end -->
This commit is contained in:
Kubernetes Submit Queue 2016-08-09 15:18:35 -07:00 committed by GitHub
commit e877a23b4b
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
docs/design/indexed-job.md
View File

@ -103,7 +103,7 @@ and can refer to it from other resource types, such as
Here are several examples of *work lists*: lists of command lines that the user
wants to run, each line its own Pod. (Note that in practice, a work list may not
ever be written out in this form, but it exists in the mind of the Job creator,
and it is a useful way to talk about the the intent of the user when discussing
and it is a useful way to talk about the intent of the user when discussing
alternatives for specifying Indexed Jobs).
Note that we will not have the user express their requirements in work list
@ -387,7 +387,7 @@ equal to the number of work items in the work list.
Each pod that the job controller creates is intended to complete one work item
from the work list. Since a pod may fail, several pods may, serially, attempt to
complete the same index. Therefore, we call it a a *completion index* (or just
complete the same index. Therefore, we call it a *completion index* (or just
*index*), but not a *pod index*.
For each completion index, in the range 1 to `.job.Spec.Completions`, the job
@ -564,7 +564,7 @@ before. They will have a new annotation, but pod are expected to tolerate
unfamiliar annotations.
However, if the job controller version is reverted, to a version before this
change, the jobs whose pod specs depend on the the new annotation will fail.
change, the jobs whose pod specs depend on the new annotation will fail.
This is okay for a Beta resource.
#### Job Controller Changes