Another thing that we had discussed:

• Explicitly specify the api-version flag when using -o template, so that the command does not break when the default api version used by kubectl is updated.

+1. In theory it could be expanded to cli-conventions.md, though I think kubectl operates quite differently than most of our other daemons. But it still may be wise for it to cover other command-line tools besides kubectl, like simplegen, podex, etc.

VERB and VERB NOUN, not NOUN VERB. We may need to reconsider kubectl config.

That being said, if you have sets of functionality that are distinct, sometimes it's nice to keep them separate (treat kubectl config like kubectl-config).

On May 13, 2015, at 7:43 PM, Brian Grant notifications@github.com wrote:

VERB and VERB NOUN, not NOUN VERB. We may need to reconsider kubectl config.

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

Also output conventions: #7843 (comment)

More output conventions: #3894 (comment)

More output conventions: #8476

Only use templates when writing reusable scripts. Human output formats may change.

Errors output to stderr rather than (or in addition to) glog: #9357

cc @janetkuo

More output conventions:

• the ability to specify labels as columns using -L Printing resource labels as columns #9876
• AGE of every object Add age column for all resources when using 'kubect get' #10008
• -o wide for wide get output Implement 'kubectl get ... -o wide' #10491
• human-understandable output from mutations (create/update/delete) by default: resource/name verbed kubectl get etc. should support a -o name (or similar option) for showing only kind/name, and make mutations more verbose by default #5906
• -o name for mutations to output just resource/name kubectl get etc. should support a -o name (or similar option) for showing only kind/name, and make mutations more verbose by default #5906

We also want conventions for:

1. Showing what a mutation would do, without doing it, aka --dry-run
2. Showing what a mutation did, by automatically getting the current object
3. Printing or describing (Describers should be able to print objects from somewhere besides the server #4471) a local object rather than one fetched from the server

All of these should be orthogonal to output format (default, wide, json, yaml, template).