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.

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

[rcf] do not allow experimental features if client/daemon versions don't match #28655

Closed
thaJeztah opened this issue Nov 21, 2016 · 1 comment
Labels
kind/enhancement Enhancements are not bugs or new features but can improve usability or performance. kind/experimental
Milestone

Comments

@thaJeztah
Copy link
Member

thaJeztah commented Nov 21, 2016

Starting with docker 1.13 we allow newer clients to work with older
daemon versions, and "detect" if experimental features are enabled
on the daemon.

Given that experimental features can (and in many cases, will) change
before they leave experimental, this can result in unexpected behavior.

For example, if the "checkpoint / restore" feature leaves experimental
in 1.14, and a 1.14 client communicates with a 1.13 daemon, it will no
longer check if experimental features are enabled on the daemon (because
according to the client, the feature is no longer experimental).

The daemon on its side, will allow requests to the "checkpoint" API
endpoints if the --experimental flag is set.

I think we should prevent this, for example:

  1. a client should only allow running experimental options if the client
    and daemon versions match
  2. a daemon should also only allow access to experimental API endpoints
    if the client has the same version (actual version, not downgrade
    / upgraded API version)
  3. if a feature leaves experimental, the minimum API version of the
    related endpoints should be set to the version in which it left experimental.

I'm not sure if 2. is possible; does the client request contain information
that it downgraded / upgraded the API version?

Perhaps parts of this are already in place, but opening this issue
so that we don't forget checking before GA 😄

/cc @vieux

@thaJeztah thaJeztah added kind/enhancement Enhancements are not bugs or new features but can improve usability or performance. kind/experimental labels Nov 21, 2016
@thaJeztah thaJeztah added this to the 1.13.0 milestone Nov 21, 2016
@justincormack
Copy link
Contributor

SGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement Enhancements are not bugs or new features but can improve usability or performance. kind/experimental
Projects
None yet
Development

No branches or pull requests

3 participants