In pkg/apis/extensions/v1beta1/conversion.go,
some conversion code was copied from the
legacy api because Pod conversions cannot be
automatically generated because of something
about deprecatedServiceAccount.
This PR fixes two problems due to that copying.
First, the copied code could drift from its source
To fix that, I replaced the Convert_api_ and Convert_v1
implementations with a call to the original function.
I left a wrapper in case something needed to have
a package-local function name.
Second, the copied Convert_* functions, were copied,
in a way that they refer to other conversion functions
that aren't in the current package. This prevented
genconverion from working from a clean start
(no conversion_generated.go). Perhaps the person
who wrote this in the first place had copied
the conversion_generated.go file from legacy,
so it worked. So, I added the v1
package name to calls to Convert_* functions.
So, when someone Cargo-Cult copies the conversion.go
file, like I did, they now will not have to
wonder why genconversion complains about missing
Convert_ functions.
Deleted the conversion_generated.go and reran genconversion
and it worked, no diffs old vs new conversion_generated.go.
Move type LabelSelector and type LabelSelectorRequirement from pkg/apis/extensions
This avoids an import loop when Job (and later DaemonSet, Deployment, ReplicaSet)
are moved out of extensions to new api groups.
Also Move LabelSelectorAsSelector utility from pkg/apis/extensions/ to pkg/api/unversioned/
Also its test.
Also LabelSelectorOp* constants.
Also the pkg/apis/extensions/validation functions ValidateLabelSelectorRequirement and
ValidateLabelSelector move to pkg/api/unversioned
The related type in pkg/apis/extensions/v1beta1/ is staying there. I might move
it in another PR if neccessary.
This commit adds support for paused deployments so a user can choose
when to run a deployment that exists in the system instead of having
the deployment controller automatically reconciling it after every
change or sync interval.
When job.spec.completions is nil, only
one task needs to succeed for the job to succeed,
and parallelism can be scaled freely during runtime.
Added tests.
Release Note:
This causes two minor changes to the API.
First, unset parallelism previously was defaulted to be
equal to completions. Now it always defaults to 1 if unset.
Second, having parallelism=N and completions unset would previously
be defaulted to 1 completion and N parallelism.
(this is not something we expect people to do, though)
Now, no defaulting occurs in that case, and the job's
behavior is different (any completion causes success).
