kubectl get etc. should support a -o name (or similar option) for showing only kind/name, and make mutations more verbose by default

[smarterclayton]

With #5903 commands will support "resource/name" as an arg, which means having -q (show only type/name) becomes valuable for chaining:

$ kubectl get pods -q | grep "-builder" | xargs kubectl delete

[smarterclayton]

If we have -q, then we can make the default "create"/"update"/"delete"/"stop" commands be more verbose about what they are creating, which addresses #5579

[bgrant0607]

We should document xargs usage somewhere.

We might as well also use this issue for making the default output more verbose.

[bgrant0607]

Currently kubectl just prints object names without the kind. If they output kind/name instead, that would be more useful for this purpose.

[smarterclayton]

For get, you mean?

On Apr 24, 2015, at 6:47 PM, Brian Grant notifications@github.com wrote:

Currently kubectl just prints object names without the kind. If they output kind/name instead, that would be more useful for this purpose.

—
Reply to this email directly or view it on GitHub.

[bgrant0607]

Hmm. kubectl sort of prints the kind now.

If I create a file, say, with a v1beta3 RC and a service and do kubectl create -f unified.yaml, the output is:

replicationControllers/nginx-controller
services/nginx-example

I thought it didn't include the kind, but it does now, except that replicationControllers shouldn't be camelCase, esp. for v1beta3.

[smarterclayton]

The default resource name output hasn't changed yet, probably due to ordering in latest.RESTMapper. Will take a look at that.

On Apr 25, 2015, at 12:17 AM, Brian Grant notifications@github.com wrote:

Hmm. kubectl sort of prints the kind now.

If I create a file, say, with a v1beta3 RC and a service and do kubectl create -f unified.yaml, the output is:

replicationControllers/nginx-controller
services/nginx-example
I thought it didn't include the kind, but it does now, except that replicationControllers shouldn't be camelCase, esp. for v1beta3.

—
Reply to this email directly or view it on GitHub.

[bgrant0607]

Maybe this could just be another output format, like -o name.

[smarterclayton]

Sounds like it.

On May 29, 2015, at 2:17 AM, Brian Grant notifications@github.com wrote:

Maybe this could just be another output format, like -o name.

—
Reply to this email directly or view it on GitHub.

[bgrant0607]

Discussion of script output vs. human-oriented output: #3894 (comment)

[bgrant0607]

The default terse output was cited as a source of confusion in our usability study. People didn't know whether it meant success, failure, a tool bug, or something else.

[bgrant0607]

We should probably spawn another issue for this, but putting here for expedience and consistency...
Feedback from user: Output of success is just the name of the resource (services/redis-slave) Would be friendlier as "Service 'redis-slave' created successfully"

“kubectl create returns a line of text ‘replacationcontrollers/redis-master’ is this an error? or success? (unix cmds usually produce no output on success)”

[satnam6502]

What's the status here? Shall we go ahead and add a -q flag that reports resources in the resource/name format for use with xargs? If yes happy to take this on.

[smarterclayton]

I think brian's proposal was an alternate output mode ("-o simple" or "-o quick") handled by the printer. Then change the default output to not be xargs compatible but be friendlier.

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

What's the status here? Shall we go ahead and add a -q flag that reports
resources in the resource/name format for use with xargs? If yes happy to
take this on.

---

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

[bgrant0607]

@smarterclayton is correct. I suggest -o name or -o id to request the kind/name format, both for mutations and for get.

[smarterclayton]

Name makes a lot of sense.

On Jun 16, 2015, at 11:56 AM, Brian Grant notifications@github.com wrote:

@smarterclayton is correct. I suggest -o name or -o id to request the kind/name format, both for mutations and for get.

—
Reply to this email directly or view it on GitHub.

[janetkuo]

@bgrant0607 -o isn't supported in all kubectl commands. Should we use -q name instead to make it work for both get and mutations?

[smarterclayton]

I think we should eventually support -o on all commands - it's mostly that
we haven't gone back to create/update/delete since they were the first
commands.

On Jun 30, 2015, at 5:24 PM, Janet Kuo notifications@github.com wrote:

@bgrant0607 https://github.com/bgrant0607 -o isn't supported in all
kubectl commands. Should we use -q name instead to make it work for both
get and mutations?

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

[janetkuo]

Discussed with @bgrant0607 and decided to add the following changes to only mutations*:

• Add -o name (prints current kind/name output)
• Make default output more verbose/understandable (such as [object_name] [operation] successfully)

*Mutations include: create, delete, expose, label, patch, replace, rollingupdate, run, scale, stop

[bgrant0607]

cc @deads2k

[bgrant0607]

Later PRs can:

• add -o name to get
• add -o json|yaml|template to mutations (applied to status object in apiserver response)

[deads2k]

I like the idea of human readable by default and a separate flag for machine readable output flag. -o name sounds fine, but how well will this play with --all-namespaces? I'll get back a list of kind(resource?)/name, but that won't be sufficient to lookup when it gets piped. Can we choose a machine readable format that is fully qualifying?

[bgrant0607]

@deads2k I agree that --all-namespaces is problematic. That's a separate issue -- #3731. The form kubectl accepts on its command line would need to be extended with namespace if we wanted to add namespace to the output.

[janetkuo]

Some mutations (label, run, expose, rollingupdate) use -o flag and print the object like get does. I'll add -o name to other mutations (create, delete, stop, replace, patch, scale) first and deal with those mutations later.

[bgrant0607]

@janetkuo points out that label, run, expose, and rolling-update commands don't adhere to the same output conventions as other mutations. We'll want to fix that. For instance, label is just another kind of patch, basically.

[bgrant0607]

When writing the user guide, it was definitely jarring that run and expose produced get output.