Most of the contents of docs/ has moved to kubernetes.github.io.
Development of the docs and accompanying files has continued there, making
the copies in this repo stale. I've removed everything but the .md files
which remain to redirect old links. The .yaml config files in the docs
were used by some tests, these have been moved to test/fixtures/doc-yaml,
and can remain there to be used by tests or other purposes.
resource.Builder should prohibit empty resource names (the error is from
the wrong place) so that commands that work on multiple resources but
not resource types can properly limit errors.
Automatic merge from submit-queue
update resource builder error message to be more clear
release-note-none
The error message given by command line `kubectl get` is sometimes of no help / not clear on what must be corrected, e.g.：
`kubectl get pod pod/database-1-i10b9`
error: when passing arguments in resource/name form, all arguments must include the resource
##### Steps to Reproduce:
1. Run command "$ kubectl get pod pod/database-1-i10b9"
##### Actual Result:
Get unfriendly error message which is of no help:
"error: when passing arguments in resource/name form, all arguments must include the resource"
##### Expected Result:
Error message should recommend end user to run this cli in good grammar: "$ kubectl get pod database-1-i10b9" or "$ kubectl get pod/database-1-i10b9"
##### Before
"error: when passing arguments in resource/name form, all arguments must include the resource"
##### After
"error: there is no need to specify a resource type as a separate argument when passing arguments in resource/name form (e.g. `kubectl get resource/<resource_name>` instead of `kubectl get resource resource/<resource_name>`"
[]()
Automatic merge from submit-queue
Fixed misleading error message when a resource with no selector or na…
Commit:
- Fixed misleading error message when a resource with no selector or name is provided to kubectl delete or label command
This commit fixes#25541
The current helpful message loses the error type, which means
resource.Builder consumers can't filter errors or have downstream logic.
If the error is a known type, only mutate the message, not the message
type.
Automatic merge from submit-queue
fix recursive & non-recursive kubectl get of generic output format
This PR fixes the issues with `kubectl get` in https://github.com/kubernetes/kubernetes/issues/26466
Changes made:
- fix printing when using the generic output format in both non-recursive & recurvise settings to ensure that errors are being shown
- add tests to check printing generic output in a **non-recursive** setting with non-existent pods
- clean up the **recursive** `kubectl get` tests
/cc @janetkuo
The codec factory should support two distinct interfaces - negotiating
for a serializer with a client, vs reading or writing data to a storage
form (etcd, disk, etc). Make the EncodeForVersion and DecodeToVersion
methods only take Encoder and Decoder, and slight refactoring elsewhere.
In the storage factory, use a content type to control what serializer to
pick, and use the universal deserializer. This ensures that storage can
read JSON (which might be from older objects) while only writing
protobuf. Add exceptions for those resources that may not be able to
write to protobuf (specifically third party resources, but potentially
others in the future).
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 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.
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
It should be allowed to invoke kubectl replace with a JSON file that has
no resource version set. Namespaced resources were working correctly,
but cluster resources were silently failing to lookup the current state
of the object to get the resource version because we weren't using
NamespaceIfScoped(). Added a failing test.
Most of the logic related to type and kind retrieval belongs in the
codec, not in the various classes. Make it explicit that the codec
should handle these details.
Factory now returns a universal Decoder and a JSONEncoder to assist code
in kubectl that needs to specifically deal with JSON serialization
(apply, merge, patch, edit, jsonpath). Add comments to indicate the
serialization is explicit in those places. These methods decode to
internal and encode to the preferred API version as previous, although
in the future they may be changed.
React to removing Codec from version interfaces and RESTMapping by
passing it in to all the places that it is needed.
deads2k