The decoder will return a nil gvk in case it errors out and getting
the version out of that gvk naturally will panic. Bail out as soon
as we can check that the error is non-nil. kubectl edit was the primary
victim.
Automatic merge from submit-queue
Add flag -t as shorthand for --tty
`-t` was deprecated in #12813 (Aug. 2015, about 6+ months ago).
Now remove `--template`'s shorthand `-t` and create a shorthand `-t` for `--tty` in `kubectl run`.
@kubernetes/kubectl
Automatic merge from submit-queue
kubectl: Allow []byte config fields to be set by the cli
Allows []byte config fields such as 'certificate-authority-data' to be set using `kubectl config set` commands.
Automatic merge from submit-queue
Fix session ended hint for kubectl run
Fixes#23602
Before:
```console
$ kubectl run -i --tty busybox --image=busybox
Waiting for pod default/busybox-3797442026-mt8zk to be running, status is Pending, pod ready: false
Hit enter for command prompt
/ #
/ # exit
Session ended, resume using ' busybox-3797442026-mt8zk -c busybox -i -t' command when the pod is running
↑
(incomplete command)
```
After:
```console
Session ended, resume using 'kubectl attach busybox-3797442026-mt8zk -c busybox -i -t' command when the pod is running
```
@kubernetes/kubectl
Automatic merge from submit-queue
Make kubectl edit not convert GV on edits
Previously, kubectl edit was using a decoder to load in edits that
converted to the internal version. It would then re-encode this
decoded value to produce a patch. However, if you were editing
in the object in a GroupVersion that was not the internal version,
this would cause the kubectl edit command to attempt to produce
a patch which changed the GroupVersion, which would fail.
Now, we use a plain deserializer instead, so no conversion or
defaulting occurs when loading in the edited file.
Ref #23378
Automatic merge from submit-queue
phase 2 of cassandra example overhaul
Here's the next iteration in overhauling this example, towards https://github.com/kubernetes/kubernetes/issues/20961. This removes the pod adoption part, but doesn't (yet) otherwise change any of the resources used.
It also includes some README cleanup, and removes some explicit specification of labels in the rc yaml.
This PR doesn't yet add any commentary on how we're using the seed provider (re: https://github.com/kubernetes/kubernetes/issues/20961#issuecomment-190405959 etc.). Maybe we should add that.
Also: LMK if this PR should include any changes to the links out to the docs.
cc @bgrant0607 @johndmulhausen
Automatic merge from submit-queue
Make kubectl bash-completion namespace and resource alias aware
- filter resource listing by `--namespace` flag given before in the command line
```bash
$ kubectl get pod --namespace=kube-system <tab><tab>
kube-dns-v9-2wuzj kube-dns-v9-llqxa
```
- add completion of `--namespace`
```bash
$ kubectl get pod --namespace=<tab><tab>
[*] default ingress kube-system
```
- add support for plural nouns and aliases like `rc`
Automatic merge from submit-queue
Additional go vet fixes
Mostly:
- pass lock by value
- bad syntax for struct tag value
- example functions not formatted properly
Automatic merge from submit-queue
Refactor streaming code to support interop testing
Refactor exec/attach/port forward client and server code to better
support interop testing of different client and server subprotocol
versions.
Fixes#16119
Automatic merge from submit-queue
Add support for 3rd party objects to kubectl
@deads2k @jlowdermilk
Instructions for playing around with this:
Run an apiserver with third party resources turned on (`--runtime-config=extensions/v1beta1=true,extensions/v1beta1/thirdpartyresources=true`)
Then you should be able to:
```
kubectl create -f rsrc.json
```
```json
{
"metadata": {
"name": "foo.company.com"
},
"apiVersion": "extensions/v1beta1",
"kind": "ThirdPartyResource",
"versions": [
{
"apiGroup": "group",
"name": "v1"
},
{
"apiGroup": "group",
"name": "v2"
}
]
}
```
Once that is done, you should be able to:
```
curl http://<server>/apis/company.com/v1/foos
```
```
curl -X POST -d @${HOME}/foo.json http://localhost:8080/apis/company.com/v1/namespaces/default/foos
```
```json
{
"kind": "Foo",
"apiVersion": "company.com/v1",
"metadata": {
"name": "baz"
},
"someField": "hello world",
"otherField": 1
}
```
After this PR, you can do:
```
kubectl create -f foo.json
```
```
kubectl get foos
```
etc.
Automatic merge from submit-queue
allow kubectl cmds to process files recursively, when given a dir
This PR accomplishes two things:
1. It creates a `--recursive` flag for use with certain `kubectl` commands that _currently_ do not process files beyond their first level of children, as seen in the issue https://github.com/kubernetes/kubernetes/issues/19767
2. It enables the ability to use the `--recursive` flag in the `kubectl` commands that currently _only_ support processing a directory up to its first level of children.
reqs:
- the kubectl cmd must support the -f | --filename flag
- the kubectl cmd must support visiting a dir one level deep,
or using more than one resource
Previously, kubectl edit was using a decoder to load in edits that
converted to the internal version. It would then re-encode this
decoded value to produce a patch. However, if you were editing
in the object in a GroupVersion that was not the internal version,
this would cause the kubectl edit command to attempt to produce
a patch which changed the GroupVersion, which would fail.
Now, we use a plain deserializer instead, so no conversion or
defaulting occurs when loading in the edited file.
Fixes#23378
Currently attach and the editor do not share the same logic for saving
and restoring the terminal, and are not suitable for nesting (when the
caller wants to create something, attach, and then delete something when
the attach is over). This commit moves the interrupt protection logic
to a util package and supports nesting interrupt handlers.
Not being logged in is a common user error, and the message we display
can be more specific to an end user. Provide a friendly message with the
server message in parethesis (in case this is a more complex server
error).
Due to rounding down for maxUnavailable, we may end up with rolling updates
that have zero surge and unavailable pods something that 1) is not allowed
as per validation, 2) blocks updates. If we end up in such a situation
set maxUnavailable to 1 on the theory that surge might not work due to
quota.
Internal types are not supposed to have json metadata (though in kubernetes
they do) as it is true with openshift types. That means sort-by must work
on versioned objects for sorting, otherwise it produces "error: metadata
is not found" error if it sorts internal types without json metadata.
This PR converts internal types objects to versioned objects and sort-by
sorts them correctly without medata error, and then it prints
corresponding internal objects in sorted order.
During a rolling update for Deployments, the total count of surge pods
is calculated by adding the desired number of pods (deployment.Spec.Replicas)
to maxSurge. During a kubectl rolling update, the total count of surge
pods is calculated by adding the original number of pods (oldRc.Spec.Replicas
via an annotation) to maxSurge. This commit changes this to use desired
replicas.
In podSecurityPolicy:
1. Rename .seLinuxContext to .seLinux
2. Rename .seLinux.type to .seLinux.rule
3. Rename .runAsUser.type to .runAsUser.rule
4. Rename .seLinux.SELinuxOptions
1,2,3 as suggested by thockin in #22159.
I added 3 for consistency with 2.
Added selector generation to Job's
strategy.Validate, right before validation.
Can't do in defaulting since UID is not known.
Added a validation to Job to ensure that the generated
labels and selector are correct when generation was requested.
This happens right after generation, but validation is in a better
place to return an error.
Adds "manualSelector" field to batch/v1 Job to control selector generation.
Adds same field to extensions/__internal. Conversion between those two
is automatic.
Adds "autoSelector" field to extensions/v1beta1 Job. Used for storing batch/v1 Jobs
- Default for v1 is to do generation.
- Default for v1beta1 is to not do it.
- In both cases, unset == false == do the default thing.
Release notes:
Added batch/v1 group, which contains just Job, and which is the next
version of extensions/v1beta1 Job.
The changes from the previous version are:
- Users no longer need to ensure labels on their pod template are unique to the enclosing
job (but may add labels as needed for categorization).
- In v1beta1, job.spec.selector was defaulted from pod labels, with the user responsible for uniqueness.
In v1, a unique label is generated and added to the pod template, and used as the selector (other
labels added by user stay on pod template, but need not be used by selector).
- a new field called "manualSelector" field exists to control whether the new behavior is used,
versus a more error-prone but more flexible "manual" (not generated) seletor. Most users
will not need to use this field and should leave it unset.
Users who are creating extensions.Job go objects and then posting them using the go client
will see a change in the default behavior. They need to either stop providing a selector (relying on
selector generation) or else specify "spec.manualSelector" until they are ready to do the former.
