Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

CLI/config roadmap #3645

Merged
merged 1 commit into from
Jan 22, 2015
Merged

CLI/config roadmap #3645

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
87 changes: 87 additions & 0 deletions docs/cli-roadmap.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More ideas, based in part on #3576:

  • We could support something like --image-version=foo, which would append a name suffix, create a label, and apply a tag to the image. That could decompose cleanly into several independent options (--name-suffix, label options, and a tag option).
  • We might also want a --registry option.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know there was some discussion of creating a special "internal/system" namespace for labels/annotations we don't expect/want users to change. I think this is important. And the CLI could perhaps block changes to labels/annotations in that namespace unless some kind of flag like --force is passed on the command line. (Arguably it's the kind of thing that should require some kind of "administrator" permission, but I realize we're not thinking about multi-tenancy yet so that aspect probably doesn't matter right now.)

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)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's an example where multiple objects on the command line and an option to dump object names only would be useful in combination: http://techoverflow.net/blog/2013/10/22/docker-remove-all-images-and-containers/

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
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note to self: #3685

* 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
7 changes: 1 addition & 6 deletions docs/roadmap.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down