Make it really hard to accidentally create a job which has an overlapping selector, while still making it possible to chose an arbitrary selector, and without adding complex constraint solving to the APIserver.
kubectl get jobs/old -o yamland tries to modify and post it, he should not create an overlapping job.
kubectl get jobs/old -o yamland tries to modify and post it, and he accidentally copies the uniquifying label from the old one, then he should not get an error from a label-key conflict, nor get erratic behavior.
extensions/v1beta1 Job remains the same.
batch/v1 Job changes change as
job.spec.manualSelector 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
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:
job.spec.manualSelectorfield and does not think about it.
UID is better than Name in that:
- it allows cross-namespace control someday if we need it.
- it is unique across all kinds.
controller-name=foo does not ensure
uniqueness across Kinds
job-name=foo has a
problem: you might have a
batch.Job and a
snazzyjob.io/types.Job – the
latter cannot use label
job-name=foo, though there is a temptation to do so.
- it uniquely identifies the controller across time. This prevents the case
where, for example, someone deletes a job via the REST api or client
(where cascade=false), leaving pods around. We don’t want those to be picked up
unintentionally. It also prevents the case where a user looks at an old job that
finished but is not deleted, and tries to select its pods, and gets the wrong
impression that it is still running.
Job name is more user friendly. It is self documenting
kubectl get pods -l job-name=myjob should do exactly what is
wanted 99.9% of the time. Automated control loops should still use the
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.
If user does specify
job.spec.selector then the user must also specify
job.spec.manualSelector. This ensures the user knows that what he is doing is
not the normal thing to do.
To prevent users from copying the
job.spec.manualSelector flag from existing
jobs, it will be optional and default to false, which means when you ask GET and
existing job back that didn’t use this feature, you don’t even see the
job.spec.manualSelector flag, so you are not tempted to wonder if you should
fiddle with it.
No required changes. Suggest moving SELECTOR to wide output of
jobs since users do not write the selector.
Remove examples that use selector and remove labels from pod templates.
kubectl get jobs -l job-name=name as the way to find pods of a job.
The following applies to Job, as well as to other types that adopt this pattern:
extensions/v1beta1gets a field called
batch/v1type will get
autoSelectorhave opposite meanings.
Note: since the internal default is changing, client library consumers that create Jobs may need to add “job.spec.manualSelector=true” to keep working, or switch to auto selectors.
Conversion is as follows:
extensions/v1beta1: the value of
__internal.Spec.ManualSelector is defaulted to false if nil, negated,
defaulted to nil if false, and written
extensions/__internal: the value of
v1beta1.SpecAutoSelector is defaulted to false if nil, negated, defaulted to
nil if false, and written to
This conversion gives the following properties.
Follow this pattern for Deployments, ReplicaSet, DaemonSet when going to v1, if it works well for job.
Docs will be edited to show examples without a
We probably want as much as possible the same behavior for Job and ReplicationController.