github/kubernetes
1
0
Fork 0
mirror of https://github.com/k3s-io/kubernetes.git synced 2025-07-22 03:11:40 +00:00
Code Issues Projects Releases Wiki Activity

Update paths after move.

Browse Source 
Also improve doc slightly.
This commit is contained in:
Eric Tune 2016-02-08 13:11:43 -08:00
parent 7734dd8d18
commit 485b0681c5
2 changed files with 16 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
docs/design/selector-generation.md
View File

@ -48,11 +48,17 @@ Make it really hard to accidentally create a job which has an overlapping select
# Proposed changes
## APIserver
## API
`extensions/v1beta1 Job` remains the same. `batch/v1 Job` changes change as follows.
There are two allowed usage modes:
Field `job.spec.noAutoSelector` is added. It controls whether selectors are automatically
generated. In automatic mode, user cannot make the mistake of creating non-unique selectors.
In manual mode, certain rare use cases are supported.
Validation is not changed. A selector must be provided, and it must select the pod template.
Defaulting changes. Defaulting happens in one of two modes:
### Automatic Mode
@ -72,10 +78,6 @@ There are two allowed usage modes:
- User puts a unique label or label(s) on pod template (required). user does think carefully about uniqueness.
- No defaulting of pod labels or the selector happen.
### Common to both modes
- Validation code ensures that the selector on the job selects the labels on the pod template, and rejects if not.
### Rationale
UID is better than Name in that:
@ -89,6 +91,10 @@ Commands like `kubectl get pods -l job-name=myjob` should do exactly what is wa
Using both gets the benefits of both, at the cost of some label verbosity.
The field is a `*bool`. Since false is expected to be much more common,
and since the feature is complex, it is better to leave it unspecified so that
users looking at a stored pod spec do not need to be aware of this field.
### Overriding Unique Labels
If user does specify `job.spec.selector` then the user must also specify `job.spec.noAutoSelector`.
@ -128,6 +134,8 @@ We probably want as much as possible the same behavior for Job and ReplicationCo
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/selector-generation.md?pixel)]()
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/selector-generation.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

2
docs/proposals/job.md
View File

@ -185,7 +185,7 @@ Below are the possible future extensions to the Job controller:
[this comment](https://github.com/kubernetes/kubernetes/issues/1624#issuecomment-97622142))
* Be able to inspect Pods running a Job, especially after a Job has finished, e.g.
by providing pointers to Pods in the JobStatus ([see comment](https://github.com/kubernetes/kubernetes/pull/11746/files#r37142628)).
* help users avoid non-unique label selectors ([see this proposal](selector-generation.md))
* help users avoid non-unique label selectors ([see this proposal](../../docs/design/selector-generation.md))
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->