Add support for experimental Cli configuration#758
Conversation
cli/command/cli.go
Outdated
| func isExperimentalCli(configfile *configfile.ConfigFile) bool { | ||
| if e := os.Getenv("DOCKER_EXPERIMENTAL_CLI"); e != "" { | ||
| value := strings.ToLower(e) | ||
| return value == "1" || value == "y" || value == "yes" |
There was a problem hiding this comment.
no support for "true"?
Probably strconv.ParseBool should be used
43d8af1 to
42186c2
Compare
cli/command/cli.go
Outdated
| } | ||
|
|
||
| func isExperimentalCli(configfile *configfile.ConfigFile) bool { | ||
| if e := os.Getenv("DOCKER_EXPERIMENTAL_CLI"); e != "" { |
There was a problem hiding this comment.
I don't think this environment variable is useful. Contrary to the DOCKER_ORCHESTRATOR one which you can use to switch between orchestrators, I think switching to experimental features should be a "long term" choice from the user.
There was a problem hiding this comment.
Agreed, we can probably skip it for now. Easy to add in future if there's a real need for it.
42186c2 to
f821c37
Compare
Codecov Report
@@ Coverage Diff @@
## master #758 +/- ##
==========================================
+ Coverage 53.45% 53.46% +0.01%
==========================================
Files 218 218
Lines 14613 14642 +29
==========================================
+ Hits 7811 7829 +18
- Misses 6321 6327 +6
- Partials 481 486 +5 |
thaJeztah
left a comment
There was a problem hiding this comment.
From a user-perspective, I wonder if we should have some connection between "server experimental" and "client experimental".
Thinking something like;
auto(default) CLI follows daemon's "experimental"disabledDisable all experimental features; hide experimental commands, even if they are enabled on the daemonenabledEnable experimental (cli) commands; experimental features that require the daemon to have experimental are still disabled
It's a bit tricky if people want to be able to enable/disable them separate (without having access to the daemon), in which case it'd become;
auto | disabled | enabled | cli-only | daemon-only? (most likely too detailed)
We'll need some documentation around this, because for users it will not be clear which features are client-side, and which ones are daemon-side.
cli/command/cli.go
Outdated
| return err | ||
| } | ||
| cli.clientInfo = ClientInfo{ | ||
| HasExperimental: isExperimentalCli(cli.configFile), |
There was a problem hiding this comment.
We probably need to add this information to the docker version output as well;
cli/cli/command/system/version.go
Lines 61 to 72 in 7138d6e
cli/command/cli.go
Outdated
| } | ||
|
|
||
| func isExperimentalCli(configfile *configfile.ConfigFile) bool { | ||
| if e := os.Getenv("DOCKER_EXPERIMENTAL_CLI"); e != "" { |
There was a problem hiding this comment.
Agreed, we can probably skip it for now. Easy to add in future if there's a real need for it.
f821c37 to
b9fd0aa
Compare
|
@thaJeztah Interesting, I like that approach 👼 |
dnephin
left a comment
There was a problem hiding this comment.
I thought we were considering calling this "beta" instead of experimental. What happened with that discussion?
cli/command/cli_test.go
Outdated
| } | ||
|
|
||
| cli := &DockerCli{client: apiclient, err: os.Stderr} | ||
| t.Log("yo ", tmpDir) |
cli/command/cli_test.go
Outdated
| } | ||
| } | ||
|
|
||
| func createTemporaryConfigfile(t *testing.T, name, content string) (string, func()) { |
There was a problem hiding this comment.
Could be replaced with
dir := fs.NewDir(t, name, fs.WithFile("config.json", content))
defer dir.Remove()
cli/command/cli.go
Outdated
| defaultVersion string | ||
| server ServerInfo | ||
| serverInfo ServerInfo | ||
| clientInfo ClientInfo |
There was a problem hiding this comment.
We could move defaultVersion to clientInfo I think, but doesn't need to happen in this PR.
cmd/docker/docker.go
Outdated
| errs = append(errs, fmt.Sprintf("\"--%s\" is only supported on a Docker daemon with experimental features enabled", f.Name)) | ||
| } | ||
| if _, ok := f.Annotations["experimentalCli"]; ok && !hasExperimentalCli { | ||
| errs = append(errs, fmt.Sprintf("\"--%s\" is only supported on a Docker cli with experimental features enabled", f.Name)) |
There was a problem hiding this comment.
"only supported when experimental cli features are enabled"
I just realized all of this was duplicated. We should be able to declare this visitor once, and call it for the root command case. Doesn't need to be part of this PR.
cmd/docker/docker.go
Outdated
| return fmt.Errorf("%s is only supported on a Docker daemon with experimental features enabled", cmd.CommandPath()) | ||
| } | ||
| if _, ok := curr.Annotations["experimentalCli"]; ok && !hasExperimentalCli { | ||
| return fmt.Errorf("%s is only supported on a Docker cli with experimental features enabled", cmd.CommandPath()) |
There was a problem hiding this comment.
"only supported when experimental cli features are enabled"
I think this implies there is some relationship between the two, when in reality there is not. I think it would be better to keep them separate. Even using different names for them would be great (beta vs experimental). |
|
The tricky bit is that something being "client side" or "daemon side" should largely be an implementation detail; most users won't be aware where the functionality lives, and I'm not sure we should put that burden onto them if not needed for the 99% (but we can still consider having more fine-grained options in addition). Some features may even move from cli to daemon (or vice versa) |
|
I think the reality is that the user needs to be aware of where it's implemented because a single client can connect to more than one server. We could maybe avoid some of the confusion by using feature flags instead of a global "experimental". So users could enable trust, or k8s-stacks, instead of enabling everything. |
b9fd0aa to
1bd2b5f
Compare
|
@thaJeztah @dnephin Updated with comments taken into account. Switch to |
1bd2b5f to
fe81004
Compare
|
Different topic, but we could really use a way to set multiple configurations (per daemon/host), either by having a |
|
@thaJeztah could we add
Yes ! This is in my TODOs 👼 |
Yes, definitely; current implementation allows expanding options (hence: not using a boolean LGTM, but awaiting @dnephin before moving to "code review" |
| case "", "disabled": | ||
| return false, nil | ||
| default: | ||
| return false, errors.Errorf("%q is not valid, should be either enabled or disabled", value) |
There was a problem hiding this comment.
Think we should mention the configuration option here, currently it shows:
$ docker version
"Moby was here" is not valid, should be either enabled or disabled
Perhaps something like:
Invalid value for "experimentalCli": "Moby was here". Valid options are "enabled" and "disabled"
(better suggestions welcome)
cli/config/configfile/file.go
Outdated
| NodesFormat string `json:"nodesFormat,omitempty"` | ||
| PruneFilters []string `json:"pruneFilters,omitempty"` | ||
| Proxies map[string]ProxyConfig `json:"proxies,omitempty"` | ||
| ExperimentalCli string `json:"experimentalCli,omitempty"` |
There was a problem hiding this comment.
CLI is an acronym, so this should be ExperimentalCLI (and experimentalCLI for JSON)
Given that this configuration file is for the CLI; is CLI a bit redundant? Perhaps just Experimental?
fe81004 to
da6a6e9
Compare
cli/command/cli.go
Outdated
| } | ||
| hasExperimental, err := isEnabled(cli.configFile.ExperimentalCli) | ||
| if err != nil { | ||
| return err |
There was a problem hiding this comment.
I guess this should errors.Wrapf(err, "ExperimentalCLI field") so that the error message mentions which field has a problem
da6a6e9 to
19a3689
Compare
deae842 to
bae6e20
Compare
cli/command/cli_test.go
Outdated
| } | ||
| } | ||
|
|
||
| func TestExperimentalCli(t *testing.T) { |
There was a problem hiding this comment.
small nit: TestExperimentalCLI to stay consistent with casing
|
LGTM |
Allow to mark some commands and flags experimental on cli (i.e. not depending to the state of the daemon). This will allow more flexibility on experimentation with the cli. Marking `docker trust` as cli experimental as it is documented so. Signed-off-by: Vincent Demeester <vincent@sbr.pm>
bae6e20 to
84fe1a1
Compare
|
thx |
Add support for experimental Cli configuration Upstream-commit: 70db7cc Component: cli
Allow to mark some commands and flags experimental on cli (i.e. not
depending to the state of the daemon). This will allow more flexibility
on experimentation with the cli.
Marking
docker trustas cli experimental as it is documented so.This is required for #721 (as we will put the k8s support under experimental at first)
Signed-off-by: Vincent Demeester vincent@sbr.pm