One wrinkle - should all include "namespaced" resources and "cluster resources", just "namespaced resources", or just "resources you actually have access to view" (because there will be some in that list that an end user probably won't have access to list)

----- Original Message -----

Forked from #3233.

I think the last proposal was to support:

kubectl describe all
kubectl describe all foo

where "all" implies all known kinds.

@brendandburns @smarterclayton

---

Reply to this email directly or view it on GitHub:
#5278

Is this a listing call or is it just short-hand for user typing:

kubectl describe pods foo
kubectl describe services foo
kubectl describe namespaces foo
...

In general, not all of resource types support describe yet if I recall, so that should probably be resolved first.

----- Original Message -----
From: "Clayton Coleman" notifications@github.com
To: "GoogleCloudPlatform/kubernetes" kubernetes@noreply.github.com
Sent: Wednesday, March 18, 2015 5:24:30 PM
Subject: Re: [kubernetes] Kind wildcarding/discovery in kubectl (#5278)

One wrinkle - should all include "namespaced" resources and "cluster resources", just "namespaced resources", or just "resources you actually have access to view" (because there will be some in that list that an end user probably won't have access to list)

----- Original Message -----

Forked from #3233.

I think the last proposal was to support:

kubectl describe all
kubectl describe all foo

where "all" implies all known kinds.

@brendandburns @smarterclayton

---

Reply to this email directly or view it on GitHub:
#5278

Reply to this email directly or view it on GitHub:
#5278 (comment)

Short hand. Eventually might be server calculated and cached locally in the config

On Mar 19, 2015, at 11:15 AM, Derek Carr notifications@github.com wrote:

Is this a listing call or is it just short-hand for user typing:

kubectl describe pods foo
kubectl describe services foo
kubectl describe namespaces foo
...

In general, not all of resource types support describe yet if I recall, so that should probably be resolved first.

----- Original Message -----
From: "Clayton Coleman" notifications@github.com
To: "GoogleCloudPlatform/kubernetes" kubernetes@noreply.github.com
Sent: Wednesday, March 18, 2015 5:24:30 PM
Subject: Re: [kubernetes] Kind wildcarding/discovery in kubectl (#5278)

One wrinkle - should all include "namespaced" resources and "cluster resources", just "namespaced resources", or just "resources you actually have access to view" (because there will be some in that list that an end user probably won't have access to list)

----- Original Message -----

Forked from #3233.

I think the last proposal was to support:

kubectl describe all
kubectl describe all foo

where "all" implies all known kinds.

@brendandburns @smarterclayton

---

Reply to this email directly or view it on GitHub:
#5278

---

Reply to this email directly or view it on GitHub:
#5278 (comment)
—
Reply to this email directly or view it on GitHub.

If its short-hand it should just be "all cluster scoped resources with name foo and all namespace scoped resources in current namespace context name foo".

----- Original Message -----
From: "Clayton Coleman" notifications@github.com
To: "GoogleCloudPlatform/kubernetes" kubernetes@noreply.github.com
Cc: "Derek Carr" decarr@redhat.com
Sent: Thursday, March 19, 2015 11:53:39 AM
Subject: Re: [kubernetes] Kind wildcarding/discovery in kubectl (#5278)

Short hand. Eventually might be server calculated and cached locally in the config

On Mar 19, 2015, at 11:15 AM, Derek Carr notifications@github.com wrote:

Is this a listing call or is it just short-hand for user typing:

kubectl describe pods foo
kubectl describe services foo
kubectl describe namespaces foo
...

In general, not all of resource types support describe yet if I recall, so that should probably be resolved first.

----- Original Message -----
From: "Clayton Coleman" notifications@github.com
To: "GoogleCloudPlatform/kubernetes" kubernetes@noreply.github.com
Sent: Wednesday, March 18, 2015 5:24:30 PM
Subject: Re: [kubernetes] Kind wildcarding/discovery in kubectl (#5278)

One wrinkle - should all include "namespaced" resources and "cluster resources", just "namespaced resources", or just "resources you actually have access to view" (because there will be some in that list that an end user probably won't have access to list)

----- Original Message -----

Forked from #3233.

I think the last proposal was to support:

kubectl describe all
kubectl describe all foo

where "all" implies all known kinds.

@brendandburns @smarterclayton

---

Reply to this email directly or view it on GitHub:
#5278

---

Reply to this email directly or view it on GitHub:
#5278 (comment)
—
Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub:
#5278 (comment)

I didn't really intend to support "all " - instead you'd have to say "pods/foo nodes/foo". That way create can do "pods/foo\nnodes/foo" and you can xargs it. If you specify a resource type for arg1 i don't think you should be allowed to specify anything except label selectors or --all.

----- Original Message -----

If its short-hand it should just be "all cluster scoped resources with name
foo and all namespace scoped resources in current namespace context name
foo".

----- Original Message -----
From: "Clayton Coleman" notifications@github.com
To: "GoogleCloudPlatform/kubernetes" kubernetes@noreply.github.com
Cc: "Derek Carr" decarr@redhat.com
Sent: Thursday, March 19, 2015 11:53:39 AM
Subject: Re: [kubernetes] Kind wildcarding/discovery in kubectl (#5278)

Short hand. Eventually might be server calculated and cached locally in the
config

On Mar 19, 2015, at 11:15 AM, Derek Carr notifications@github.com wrote:

Is this a listing call or is it just short-hand for user typing:

kubectl describe pods foo
kubectl describe services foo
kubectl describe namespaces foo
...

In general, not all of resource types support describe yet if I recall, so
that should probably be resolved first.

----- Original Message -----
From: "Clayton Coleman" notifications@github.com
To: "GoogleCloudPlatform/kubernetes" kubernetes@noreply.github.com
Sent: Wednesday, March 18, 2015 5:24:30 PM
Subject: Re: [kubernetes] Kind wildcarding/discovery in kubectl (#5278)

One wrinkle - should all include "namespaced" resources and "cluster
resources", just "namespaced resources", or just "resources you actually
have access to view" (because there will be some in that list that an end
user probably won't have access to list)

----- Original Message -----

Forked from #3233.

I think the last proposal was to support:

kubectl describe all
kubectl describe all foo

where "all" implies all known kinds.

@brendandburns @smarterclayton

---

Reply to this email directly or view it on GitHub:
#5278

---

Reply to this email directly or view it on GitHub:
#5278 (comment)
—
Reply to this email directly or view it on GitHub.

---

Reply to this email directly or view it on GitHub:
#5278 (comment)

---

Reply to this email directly or view it on GitHub:
#5278 (comment)

kubectl describe seems to know how to handle:
replicationcontroller, service, minion, node, limitrange, resourcequota, pod

kubectl get seems to know how to print something about:
pod, service, event, namespace, node, status, limitrange, resourcequota, replicationcontroller, endpoints, secret

So yeah, kubectl describe isn't nearly as knowledgeable as get

Delete across all resource kinds was requested by @Kargakis in #6511.

We should decide on the shorthand. The use case discussed in #6511 is really "delete all of the end user facing things in my namespace that match this label". I don't think it applies to nodes, events, users, tokens, security policies, or other root scoped objects (in this context). It's probably more like "stop all of these things", rather than delete. It has to be extensible when other resource types are added (it can be hardcoded, but the implementation has to be something provided via cmd.Factory).

My gut reaction was to define a ResourcesForAlias(resource string) ([]string, bool) on RESTMapper, which would be invoked by resource.Builder to expand the user input. It probably wouldn't be used in other contexts.