Change:
1. Use readiness [#620](https://github.com/GoogleCloudPlatform/kubernetes/issues/620) 1. Perhaps factor this in a way that it can be shared with [Openshift’s deployment controller](https://github.com/GoogleCloudPlatform/kubernetes/issues/1743) 1. Rolling update service as a plugin <del> 1. List supported API versions </del> <ins> 1. Kind-based filtering on object streams -- only operate on the kinds of objects specified. This would make directory-based kubectl operations much more useful. Users should be able to instantiate the example applications using `kubectl create -f <example-dir> ...` 1. Improved pretty printing of endpoints, such as in the case that there are more than a few endpoints 1. Service address/port lookup command(s) </ins> 1. List supported resources 1. Swagger lookups [#3060](https://github.com/GoogleCloudPlatform/kubernetes/issues/3060) 1. --name, --name-suffix applied during creation and updates 1. --labels and opinionated label injection: --app=foo, --tier={fe,cache,be,db}, --uservice=redis, --env={dev,test,prod}, --stage={canary,final}, --track={hourly,daily,weekly}, --release=0.4.3c2. Exact ones TBD. We could allow arbitrary values -- the keys are important. The actual label keys would be (optionally?) namespaced with kubectl.kubernetes.io/, or perhaps the user’s namespace. 1. --annotations and opinionated annotation injection: --description, --revision <del> 1. Bulk updates (similar to get, create, delete) </del> 1. Imperative updates. We'll want to optionally make these safe(r) by supporting preconditions based on the current value and resourceVersion. 1. annotation updates similar to label updates <del> 1. more user-friendly on-command-line json for patch </del> <ins> 1. other custom commands for common imperative updates 1. more user-friendly (but still generic) on-command-line json for patch </ins> 1. We also want to support the following flavors of more general updates: 1. whichever we don’t support: 1. safe update: update the full resource, guarded by resourceVersion precondition (and perhaps selected value-based preconditions) 1. forced update: update the full resource, blowing away the previous Spec without preconditions; delete and re-create if necessary <del> 1. diff/dryrun: Compare new config with current Spec </del> <ins> 1. diff/dryrun: Compare new config with current Spec [#6284](https://github.com/GoogleCloudPlatform/kubernetes/issues/6284) </ins> 1. submit/apply/reconcile/ensure/merge: Merge user-provided fields with current Spec. Keep track of user-provided fields using an annotation -- see [#1702](https://github.com/GoogleCloudPlatform/kubernetes/issues/1702). Delete all objects with deployment-specific labels. 1. --dry-run for all commands 1. Support full label selection syntax, including support for namespaces. 1. Wait on conditions [#1899](https://github.com/GoogleCloudPlatform/kubernetes/issues/1899) 1. Make kubectl scriptable: make output and exit code behavior consistent and useful for wrapping in workflows and piping back into kubectl and/or xargs (e.g., dump full URLs?, distinguish permanent and retry-able failure, identify objects that should be retried) <del> 1. Here's [an example](http://techoverflow.net/blog/2013/10/22/docker-remove-all-images-and-containers/) where multiple objects on the command line and an option to dump object names only (`-q`) would be useful in combination. </del> <ins> 1. Here's [an example](http://techoverflow.net/blog/2013/10/22/docker-remove-all-images-and-containers/) where multiple objects on the command line and an option to dump object names only (`-q`) would be useful in combination. [#5906](https://github.com/GoogleCloudPlatform/kubernetes/issues/5906) </ins> 1. Easy generation of clean configuration files from existing objects (including containers -- podex) -- remove readonly fields, status 1. Export from one namespace, import into another is an important use case 1. Derive objects from other objects

Discussion:
Simple version is done, more complex version needs work. Done, now that readiness corresponds to Running and is tracked by Kubelet status if the readiness hook is set? Done Done Do we want to do a more generic one or a less generic one? OpenShift was looking more at specific topical plugin commands ("add-volume", "set-default-resources"), but not sure how much hand-holding users need. Getting close. Exec has landed and is a replacement for ssh Attach on start remains hard. Implemented
I/we should also file issues for outstanding items without issues, and add lines for newly filed issues (e.g., command flag for run-container). Readiness is not yet used by rollingupdate. With respect to patch on the command line: I was thinking of a generic mechanism, but I could see the case for domain-aware commands, also. I think we need to better factor the command code and library code, and generic functionality vs. domain-aware functionality. Neither should ever convert to the internal representation. Domain-aware functionality (e.g., describe) should target a specific API version. Configuration generators, such as run-container, should be provided as services, or at least as separate plugin commands.
ref
ref
ref
ref
ref
ref