* Use deep copies in `PrepareForUpdate()`
* Preserve select metadata from new pod
* Use patch to add ephemeral container `kubectl debug`
* Distinguish between pod vs /ephemeralcontainers NotFound
Kubernetes-commit: 97726a50c138557522def7f753ec8581d00f0b02
This changes the `/ephemeralcontainers` subresource of `/pods` to use
the `Pod` kind rather than `EphemeralContainers`.
When designing this API initially it seemed preferable to create a new
kind containing only the pod's ephemeral containers, similar to how
binding and scaling work.
It later became clear that this made admission control more difficult
because the controller wouldn't be presented with the entire Pod, so we
updated this to operate on the entire Pod, similar to how `/status`
works.
Kubernetes-commit: d22dc5cb72a627341f4004b5d58d275f3d8773b3
--current-replicas is only meaningful when it's -1 or greater.
Also add an error message to clarify the range of --current-replicas. It
is unclear that --current-replicas=-1 means no precondition. This info
may be useful for programming purposes (i.e., shell scripting, etc.).
Kubernetes-commit: 8fd7862e6974fda28bb91286ca79dc6fa236f2f8
This is a result in Japanese language.
$ make test WHAT=./staging/src/k8s.io/kubectl/pkg/cmd/diff
[0402 07:24:05] Running tests without code coverage
FAIL: TestDiffProgram (0.00s)
diff_test.go:73: stdout = "ファイル /dev/zero と /dev/zero は同一です\n", expected = Files /dev/zero and /dev/zero are identical
"
FAIL
FAIL k8s.io/kubernetes/staging/src/k8s.io/kubectl/pkg/cmd/diff 0.045s
FAIL
make: *** [Makefile:184: test] エラー 1
Kubernetes-commit: 6b9ff98dd72503e0cad5c626f67c716d465d18b2
os.CreateTemp seems to perform the exactly same task here, and its
implementation seems having considered many more edge cases than the
implementation here. This patch uses os.CreateTemp here to avoid
reinventing the wheel.
Kubernetes-commit: de0f030bcec55944dcbf81a9eec4f4d87f76567f
As discussed during the alpha review, the ReadOnly field is not really
needed because volume mounts can also be read-only. It's a historical
oddity that can be avoided for generic ephemeral volumes as part
of the promotion to beta.
Kubernetes-commit: 555d4a12bf58f19cbd79f866e2abce13490bde40
Assume the following CRDs exist (ordered by priority, the first is the highest):
- authentications.migration.k8s.io (K=Authentications, G=migration.k8s.io)
- authentications.metal3.io (K=Authentications, G=metal3.io)
- authentications.whereabouts.cni.cncf.io (K=Authentications, G=whereabouts.cni.cncf.io)
- authentications.snapshot.storage.k8s.io (K=Authentications, G=snapshot.storage.k8s.io)
In case 'kubectl explain authentications' is ran, the highest priority definition (in this case authentications.migration.k8s.io)
is returned. In case a user wants to explain authentication CRD of a different group, --api-version flag has to be set alongside
to point to a specific group and version. E.g. --api-version=metal3.io/v1
This PR allows to dismiss --api-version flag and perform a prefix check to select a resource (e.g. CRD) whose (resource, group) pair
fully prefixes requested resource. E.g. running 'kubectl explain authentications.metal3.io' will return
description of authentications.metal3.io. The same holds for optional field path.
I.e. 'kubectl explain authentications.metal3.io.spec' will return description of spec field
of authentications.metal3.io.spec. In case no resource match is found, the search falls back
to selecting the highest priority gvr that matches the resource.
In case --api-version is set, no prefix matching is performed. To cover cases
such as 'kubectl explain authentications.metal3.io --api-version=authentications.metal3.io/v1' where
fields path coincide with the resource fully specified name (to access .metal3.io field of authentications.metal3.io).
Kubernetes-commit: 30674db1595e3a24273ceb71cbfe67bb300ad951
Ling Samuel