Automatic merge from submit-queue
add resource prefix to multiple items w/ same kind
**Release note**:
```release-note
release-note-none
```
This patch ensures that a resource prefix is added to multiple items of
the same kind, when using `kubectl get all`. Before, a prefix was added only
when a single item was returned on `kubectl get all`, but ignored if only a
single resource kind existed but multiple items for that kind were
returned.
**Example**
```
$ kubectl get all
No resources found.
$ kubectl create service loadbalancer testsvc1 --tcp=8080
$ kubectl get all
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
svc/testsvc1 172.30.119.220 172.46.100.155,172.46.100.155 8080/TCP 1h
$ kubectl create service loadbalancer testsvc2 --tcp=8081
$ kubectl get all
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
svc/testsvc1 172.30.119.220 172.46.100.155,172.46.100.155 8080/TCP 1h
svc/testsvc2 172.30.241.197 172.46.164.158,172.46.164.158 8081/TCP 1h
```
@fabianofranz
This patch ensures that a resource prefix is added to multiple items of
the same kind, when using `oc get all`. Before, a prefix was added only
when a single item was returned on `oc get all`, but ignored if only a
single resource kind existed but multiple items for that kind were
returned.
Automatic merge from submit-queue
Fixes#30562: Refactor kubectl command options to use common struct for common file params
Fixes#30562 : Refactor common go struct options in pkg/kubectl/cmd/*.go.
@pwittrock
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>`"
[]()
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
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.
Right now there is no method in the resource builder for specifying just the name of a resource. NameParam is useful when a default type is already specified with ResourceTypes.
Signed-off-by: kargakis <mkargaki@redhat.com>
Clayton Coleman