The current error-handling only checked for version annotations
on the subcommand itself, but did not check the top-level command.
This patch always traverses the command path (parents), and
prints an error if the command is not supported.
Before this change:
$ docker service
Usage: docker service COMMAND
Manage services
Options:
--help Print usage
Commands:
create Create a new service
inspect Display detailed information on one or more services
ls List services
ps List the tasks of one or more services
rm Remove one or more services
scale Scale one or multiple replicated services
update Update a service
Run 'docker service COMMAND --help' for more information on a command.
$ docker service ls
ID NAME MODE REPLICAS IMAGE
After this change:
$ DOCKER_API_VERSION=1.12 docker service
docker service requires API version 1.24, but the Docker daemon API version is 1.12
$ DOCKER_API_VERSION=1.12 docker service ls
docker service ls requires API version 1.24, but the Docker daemon API version is 1.12
$ DOCKER_API_VERSION=1.24 docker plugin --help
docker plugin requires API version 1.25, but the Docker daemon API version is 1.24
$ DOCKER_API_VERSION=1.25 docker plugin upgrade --help
docker plugin upgrade requires API version 1.26, but the Docker daemon API version is 1.25
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
In more recent versions of Cobra, `--help` parsing is done before
anything else resulting in TestDaemonCommand not actually passing. I'm
actually unsure if this test ever passed since it appears that !daemon
is not being run as part of the test suite.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
This fix is the follow up of the last commit.
In this fix:
1. If any of the parents of a command has tags, then this command's
`Args` (Args validation func) will be wrapped up. The warpped up func
will check to see if the feature is supported or not. If it is not supported,
then a not supported message is generated instead.
This fix is related to 28626.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
This fix tries to address several issues raised in 28626 where
run against a non-experimental daemon may not generate correct
error message:
1. Incorrect flags were not checked against the supported features:
```
$ docker stack --nonsense
unknown flag: --nonsense
```
2. Subcommands were not checked against the supported features:
```
$ docker stack ls
Error response from daemon: This node is not a swarm manager...
```
This fix address the above mentioned issues by:
1. Add a pre-check for FlagErrorFunc
2. Recursively check if a feature is supported for cmd and its parents.
This fix fixes 28626.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Docker 1.13 and up allows a client to communicate
with older daemons. As a result, flags may be
present that are not supported by the older daemon.
The client already _hides_ flags that are not
supported yet, but this doesn't present users
from using those flags.
This change shows an error if a flag is used
that is not supported by the daemon (either
based on the API version, or because experimental
features are not enabled).
Note that for some options, a check is already
in place in the API client. For those
options, this is just a minor enhancement
to more clearly indicate which _flag_ is
not supported.
Before this change;
DOCKER_API_VERSION=1.24 docker run -d --stop-timeout=30 busybox top
mjfyt3qpvnq0iwmun3sjwth9i
echo -e "FROM busybox\nRUN echo foo > bar" | DOCKER_API_VERSION=1.24 docker build --squash -
"squash" requires API version 1.25, but the Docker server is version 1.24
After this change;
DOCKER_API_VERSION=1.24 docker run -d --stop-timeout=30 busybox top
"--stop-timeout" requires API version 1.25, but the Docker daemon is version 1.24
echo -e "FROM busybox\nRUN echo foo > bar" | DOCKER_API_VERSION=1.24 docker build --squash -
"--squash" requires API version 1.25, but the Docker daemon is version 1.24
echo -e "FROM busybox\nRUN echo foo > bar" | docker build --squash -
"--squash" is only supported on a Docker daemon with experimental features enabled
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Cli initialization pings back to remote API and
creates a deadlock if socket is already being
listened by systemd.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Signed-off-by: Victor Vieux <vieux@docker.com>
update cobra and use Tags
Signed-off-by: Victor Vieux <vieux@docker.com>
allow client to talk to an older server
Signed-off-by: Victor Vieux <vieux@docker.com>
The daemon is in a separate (dockerd) binary
since docker 1.12, so should no longer be
used.
This marks the command as deprecated, and
adds it to the deprecated features list.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Support args to RunCommand
Fix docker help text test.
Fix for ipv6 tests.
Fix TLSverify option.
Fix TestDaemonDiscoveryBackendConfigReload
Use tempfile for another test.
Restore missing flag.
Fix tests for removal of shlex.
Signed-off-by: Daniel Nephin <dnephin@docker.com>
Also consolidate the leftover packages under cli.
Remove pkg/mflag.
Make manpage generation work with new cobra layout.
Remove remaining mflag and fix tests after rebase with master.
Signed-off-by: Daniel Nephin <dnephin@docker.com>
Cleanup cobra integration
Update windows files for cobra and pflags
Cleanup SetupRootcmd, and remove unnecessary SetFlagErrorFunc.
Use cobra command traversal
Signed-off-by: Daniel Nephin <dnephin@docker.com>
This works around golang/go#15286 by explicitly loading shell32.dll at
load time, ensuring that syscall can load it dynamically during process
startup.
Signed-off-by: John Starks <jostarks@microsoft.com>
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
before:
```
$ time docker --help
real 0m0.177s
user 0m0.000s
sys 0m0.040s
```
after:
```
$ time docker --help
real 0m0.010s
user 0m0.000s
sys 0m0.000s
```
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
This adds support for Windows dockerd to run as a Windows service, managed
by the service control manager. The log is written to the Windows event
log (and can be viewed in the event viewer or in PowerShell). If there is
a Go panic, the stack is written to a file panic.log in the Docker root.
Signed-off-by: John Starks <jostarks@microsoft.com>
