mirror of
https://github.com/optim-enterprises-bv/kubernetes.git
synced 2025-11-04 04:08:16 +00:00
First draft of CLI/config roadmap.
This commit is contained in:
Brian Grant
87
docs/cli-roadmap.md
Normal file
87
docs/cli-roadmap.md
Normal file
@@ -0,0 +1,87 @@
|
||||
# Kubernetes CLI/Configuration Roadmap
|
||||
|
||||
See also issues with the following labels:
|
||||
* [area/config-deployment](https://github.com/GoogleCloudPlatform/kubernetes/labels/area%2Fconfig-deployment)
|
||||
* [component/CLI](https://github.com/GoogleCloudPlatform/kubernetes/labels/component%2FCLI)
|
||||
* [component/client](https://github.com/GoogleCloudPlatform/kubernetes/labels/component%2Fclient)
|
||||
|
||||
At least the first three issues should block 1.0.
|
||||
|
||||
1. stop command in kubectl [#2144](https://github.com/GoogleCloudPlatform/kubernetes/issues/2144): Gracefully terminate any object(s), to the extent currently possible. We also eventually want first-class support in the API for graceful termination. [#1535](https://github.com/GoogleCloudPlatform/kubernetes/issues/1535)
|
||||
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. Create services before other objects, or at least before objects that depend upon them. Namespace-relative DNS mitigates this some, but most users are still using service environment variables. [#1768](https://github.com/GoogleCloudPlatform/kubernetes/issues/1768)
|
||||
1. Pretty printing of endpoints
|
||||
1. Service address/port lookup command(s)
|
||||
1. Multiple objects on command line [#3050](https://github.com/GoogleCloudPlatform/kubernetes/issues/3050)
|
||||
1. Finish rolling update [#1353](https://github.com/GoogleCloudPlatform/kubernetes/issues/1353)
|
||||
1. Friendly to auto-scaling [#2863](https://github.com/GoogleCloudPlatform/kubernetes/pull/2863#issuecomment-69701562)
|
||||
1. Rollback (make rollingupdate reversible, and complete an in-progress rolling update by taking 2 replication controller names rather than always taking a file)
|
||||
1. Rollover (replace multiple replication controllers with one, such as to clean up an aborted partial rollout)
|
||||
1. Write a ReplicationController generator to derive the new ReplicationController from an old one (e.g., `--image-version=newversion`, which would apply a name suffix, update a label value, and apply an image tag)
|
||||
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
|
||||
1. List supported API versions
|
||||
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
|
||||
1. Bulk updates (similar to get, create, delete)
|
||||
1. Imperative updates. We'll want to optionally make these safe(r) by supporting preconditions based on the current value and resourceVersion.
|
||||
1. label updates: addlabel, rmlabel, changelabel
|
||||
1. annotation updates: addannotation, rmannotation, changeannotation
|
||||
1. more user-friendly on-command-line json for patch
|
||||
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
|
||||
1. diff/dryrun: Compare new config with current Spec
|
||||
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)
|
||||
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.
|
||||
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
|
||||
1. pod clone
|
||||
1. rc from pod
|
||||
1. --labels-from (services from pods or rcs)
|
||||
1. Kind discovery (i.e., operate on objects of all kinds) [#3233](https://github.com/GoogleCloudPlatform/kubernetes/pull/3233)
|
||||
1. A fairly general-purpose way to specify fields on the command line during creation and update, not just from a config file
|
||||
1. Extensible API-based generator framework (i.e. invoke generators via an API/URL rather than building them into kubectl), so that complex client libraries don’t need to be rewritten in multiple languages, and so that the abstractions are available through all interfaces: API, CLI, UI, logs, ...
|
||||
1. Need schema registry, and some way to invoke generator (e.g., using a container)
|
||||
1. Convert run-container to API-based generator
|
||||
1. Transformation framework
|
||||
1. More intelligent defaulting of fields (e.g., [#2643](https://github.com/GoogleCloudPlatform/kubernetes/issues/2643))
|
||||
1. Update preconditions based on the values of arbitrary object fields.
|
||||
1. Deployment manager compatibility on GCP: [#3685](https://github.com/GoogleCloudPlatform/kubernetes/issues/3685)
|
||||
|
||||
TODO:
|
||||
* watch
|
||||
* ssh [#1513](https://github.com/GoogleCloudPlatform/kubernetes/issues/1513)
|
||||
* attach [#1521](https://github.com/GoogleCloudPlatform/kubernetes/issues/1521)
|
||||
* image/registry commands
|
||||
* do any other server paths make sense? validate? generic curl functionality?
|
||||
* template parameterization
|
||||
* dynamic/runtime configuration
|
||||
|
||||
Server-side support:
|
||||
|
||||
Only finishing v1beta3 is a requirement for 1.0. The others are strong nice-to-haves.
|
||||
|
||||
1. Finish v1beta3
|
||||
1. Default selectors from labels [#1698](https://github.com/GoogleCloudPlatform/kubernetes/issues/1698#issuecomment-71048278)
|
||||
1. List supported resources [#2057](https://github.com/GoogleCloudPlatform/kubernetes/issues/2057)
|
||||
1. Stop [#1535](https://github.com/GoogleCloudPlatform/kubernetes/issues/1535)
|
||||
1. Deleted objects [#2789](https://github.com/GoogleCloudPlatform/kubernetes/issues/2789)
|
||||
1. Clone [#170](https://github.com/GoogleCloudPlatform/kubernetes/issues/170)
|
||||
1. Resize [#1629](https://github.com/GoogleCloudPlatform/kubernetes/issues/1629)
|
||||
1. Useful /operations API: wait for finalization/reification
|
||||
1. Readiness [#620](https://github.com/GoogleCloudPlatform/kubernetes/issues/620)
|
||||
1. Reverse label lookup [#1348](https://github.com/GoogleCloudPlatform/kubernetes/issues/1348)
|
||||
1. Field selection [#1362](https://github.com/GoogleCloudPlatform/kubernetes/issues/1362)
|
||||
1. Field filtering [#1459](https://github.com/GoogleCloudPlatform/kubernetes/issues/1459)
|
||||
1. Operate on uids
|
||||
@@ -82,12 +82,7 @@ Which exact stateful applications are TBD. Candidates include:
|
||||
3. OS + kernel + Docker
|
||||
|
||||
### Workload deployment and management
|
||||
1. Kubectl fully replaces kubecfg [#2144](https://github.com/GoogleCloudPlatform/kubernetes/issues/2144)
|
||||
1. Graceful termination. [#1535](https://github.com/GoogleCloudPlatform/kubernetes/issues/1535)
|
||||
2. Resize. [#1629](https://github.com/GoogleCloudPlatform/kubernetes/issues/1629)
|
||||
3. Config generators integrated into kubectl.
|
||||
4. Rolling updates. [#1353](https://github.com/GoogleCloudPlatform/kubernetes/issues/1353)
|
||||
2. Kubectl can perform bulk operations (e.g., delete) on streams of API objects [#1905](https://github.com/GoogleCloudPlatform/kubernetes/issues/1905)
|
||||
See the [CLI/configuration roadmap](cli-roadmap.md) for details.
|
||||
|
||||
## Productionization
|
||||
1. Scalability
|
||||
|
||||
Reference in New Issue
Block a user