Prior to this change, progressbars would sometimes be hidden, and the function
would return early. In addition, the direction of the progressbars would sometimes
be "incrementing" (similar to "docker service update"), and sometimes be "decrementing"
(to indicate a "rollback" is being performed).
This fix makes sure that we always proceed with the "verifying" step, and now
prints a message _after_ the verifying stage was completed;
$ docker service rollback foo
foo
overall progress: rolling back update: 5 out of 5 tasks
1/5: running [> ]
2/5: starting [===========> ]
3/5: starting [===========> ]
4/5: running [> ]
5/5: running [> ]
verify: Service converged
rollback: rollback completed
$ docker service rollback foo
foo
overall progress: rolling back update: 1 out of 1 tasks
1/1: running [> ]
verify: Service converged
rollback: rollback completed
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 104469be0b)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Before this change:
--------------------------------------------
$ docker service create --replicas=1 --name foo -p 8080:80 nginx:alpine
t33qvykv8y0zbz266rxynsbo3
overall progress: 1 out of 1 tasks
1/1: running [==================================================>]
verify: Service converged
$ echo $?
0
$ docker service update --replicas=5 foo
foo
overall progress: 5 out of 5 tasks
1/5: running [==================================================>]
2/5: running [==================================================>]
3/5: running [==================================================>]
4/5: running [==================================================>]
5/5: running [==================================================>]
verify: Service converged
$ echo $?
0
$ docker service rollback foo
foo
rollback: manually requested rollback
overall progress: rolling back update: 1 out of 1 tasks
1/1: running [> ]
verify: Service converged
$ echo $?
0
$ docker service rollback foo
foo
service rolled back: rollback completed
$ echo $?
1
After this change:
--------------------------------------------
$ docker service create --replicas=1 --name foo -p 8080:80 nginx:alpine
t33qvykv8y0zbz266rxynsbo3
overall progress: 1 out of 1 tasks
1/1: running [==================================================>]
verify: Service converged
$ echo $?
0
$ docker service update --replicas=5 foo
foo
overall progress: 5 out of 5 tasks
1/5: running [==================================================>]
2/5: running [==================================================>]
3/5: running [==================================================>]
4/5: running [==================================================>]
5/5: running [==================================================>]
verify: Waiting 1 seconds to verify that tasks are stable...
$ echo $?
0
$ docker service rollback foo
foo
rollback: manually requested rollback
overall progress: rolling back update: 1 out of 1 tasks
1/1: running [> ]
verify: Service converged
$ echo $?
0
$ docker service rollback foo
foo
service rolled back: rollback completed
$ echo $?
0
$ docker service ps foo
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
4dt4ms4c5qfb foo.1 nginx:alpine docker-desktop Running Running 2 minutes ago
Remaining issues with reconciliation
--------------------------------------------
Note that both before, and after this change, the command sometimes terminates
early, and does not wait for the service to reconcile; this is most apparent
when rolling back is scaling up (so more tasks are deployed);
$ docker service rollback foo
foo
service rolled back: rollback completed
$ docker service rollback foo
foo
rollback: manually requested rollback
overall progress: rolling back update: 1 out of 5 tasks
1/5: pending [=================================> ]
2/5: running [> ]
3/5: pending [=================================> ]
4/5: pending [=================================> ]
5/5: pending [=================================> ]
service rolled back: rollback completed
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit ce26a165b0)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit f32731f902 fixed a potential panic
when an error was returned while trying to get existing credentials.
However, other code paths currently use the result of `GetDefaultAuthConfig()`
even in an error condition; this resulted in a panic, because a `nil` was
returned.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit c2820a7e3b)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
commit c2626a8270 replaced the use of
github.com/docker/docker/pkg/homedir with Golang's os.UserHomeDir().
This change was partially reverted in 7a279af43d
to account for situations where `$HOME` is not set.
In situations where no configuration file is present in `~/.config/`, the CLI
falls back to looking for the (deprecated) `~/.dockercfg` configuration file,
which was still using `os.UserHomeDir()`, which produces an error/warning if
`$HOME` is not set.
This patch introduces a helper function and a global variable to get the user's
home-directory. The global variable is used to prevent repeatedly looking up
the user's information (which, depending on the setup can be a costly operation).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit c85a37dbb4)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These options were deprecated and removed in the Linux kernel v5.0 and up in;
- f382fb0bce
- fb5772cbfe
- 23aa16489c
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit fb2ea098a9)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
On Windows, the os/exec.{Command,CommandContext,LookPath} functions
resolve command names that have neither path separators nor file extension
(e.g., "git") by first looking in the current working directory before
looking in the PATH environment variable.
Go maintainers intended to match cmd.exe's historical behavior.
However, this is pretty much never the intended behavior and as an abundance of precaution
this patch prevents that when executing commands.
Example of commands that docker.exe may execute: `git`, `docker-buildx` (or other cli plugin), `docker-credential-wincred`, `docker`.
Note that this was prompted by the [Go 1.15.7 security fixes](https://blog.golang.org/path-security), but unlike in `go.exe`,
the windows path lookups in docker are not in a code path allowing remote code execution, thus there is no security impact on docker.
Signed-off-by: Tibor Vass <tibor@docker.com>
(cherry picked from commit 8d199d5bba)
Signed-off-by: Tibor Vass <tibor@docker.com>
The created time of the containerd is initialized with nanoseconds,
it seems to be a mistake.
In other places of the code, this field is initialized with seconds:
$ grep -rh 'time\.Now()\.Unix()' | grep Created
Created: time.Now().Unix(),
Created: time.Now().Unix(),
return []image.HistoryResponseItem{{ID: img, Created: time.Now().Unix()}}, nil
We can also see the the formatter assumes it to be seconds:
cli/command/formatter/container.go
----
func (c *ContainerContext) CreatedAt() string {
return time.Unix(c.c.Created, 0).String()
}
Interestingly, initializing the field with nanoseconds seems to work,
except on mips architecture, where it causes some kind of overflow.
~~~~
=== Failed
=== FAIL: cli/command/container TestContainerListWithoutFormat (0.00s)
list_test.go:183: assertion failed:
--- expected
+++ actual
@@ -1,7 +1,7 @@
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
-container_id busybox:latest "top" Less than a second ago Up 1 second c1
-container_id busybox:latest "top" Less than a second ago Up 1 second c2
-container_id busybox:latest "top" Less than a second ago Up 1 second 80-82/tcp c3
-container_id busybox:latest "top" Less than a second ago Up 1 second 81/udp c4
-container_id busybox:latest "top" Less than a second ago Up 1 second 8.8.8.8:82->82/tcp c5
+container_id busybox:latest "top" -153722867 minutes ago Up 1 second c1
+container_id busybox:latest "top" -153722867 minutes ago Up 1 second c2
+container_id busybox:latest "top" -153722867 minutes ago Up 1 second 80-82/tcp c3
+container_id busybox:latest "top" -153722867 minutes ago Up 1 second 81/udp c4
+container_id busybox:latest "top" -153722867 minutes ago Up 1 second 8.8.8.8:82->82/tcp c5
=== FAIL: cli/command/container TestContainerListNoTrunc (0.00s)
list_test.go:198: assertion failed:
--- expected
+++ actual
@@ -1,4 +1,4 @@
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
-container_id busybox:latest "top" Less than a second ago Up 1 second c1
-container_id busybox:latest "top" Less than a second ago Up 1 second c2,foo/bar
+container_id busybox:latest "top" -153722867 minutes ago Up 1 second c1
+container_id busybox:latest "top" -153722867 minutes ago Up 1 second c2,foo/bar
~~~~
Logs above taken from:
https://buildd.debian.org/status/fetch.php?pkg=docker.io&arch=mipsel&ver=20.10.0%7Erc1%2Bdfsg3-1&stamp=1606895899
~~~~
=== RUN TestChtimesLinux
chtimes_linux_test.go:87: Expected: 2262-04-11 23:47:16 +0000 UTC, got: 1990-01-27 10:50:44 +0000 UTC
--- FAIL: TestChtimesLinux (0.00s)
=== RUN TestChtimes
chtimes_test.go:92: Expected: 2262-04-11 23:47:16 +0000 UTC, got: 1990-01-27 10:50:44 +0000 UTC
--- FAIL: TestChtimes (0.00s)
~~~~
Logs above taken from:
https://buildd.debian.org/status/fetch.php?pkg=docker.io&arch=mips64el&ver=20.10.0%7Erc1%2Bdfsg3-1&stamp=1606895622
Signed-off-by: Arnaud Rebillout <elboulangero@gmail.com>
Distributions uses generate-man.sh to create man pages, however it only
assumes a container environment and attempts to build binaries towards
`/go` which might be an illegal path in `fakeroot`.
This patch ensures we only build `md2man` from the vendored sources if
the command is not present. This allows distributions to supply thier
packaged `md2man`.
Signed-off-by: Morten Linderud <morten@linderud.pw>
Docker Engine v20.10 and up includes optimizations to verify if images in the
local image cache need updating before pulling, preventing the Docker Engine
from making unnecessary API requests. These optimizations require the container
image registry to conform to the Open Container Initiative Distribution Specification
(https://github.com/opencontainers/distribution-spec).
While most registries conform to the specification, we encountered some registries
to be non-compliant, resulting in `docker pull` to fail.
As a temporary solution, Docker Engine v20.10 includes a fallback mechanism to
allow `docker pull` to be functional when using a non-compliant registry. A
warning message is printed in this situation:
WARNING Failed to pull manifest by the resolved digest. This registry does not
appear to conform to the distribution registry specification; falling back to
pull by tag. This fallback is DEPRECATED, and will be removed in a future
release.
The fallback is added to allow users to either migrate their images to a compliant
registry, or for these registries to become compliant.
Note that this fallback only addresses failures on `docker pull`. Other commands,
such as `docker stack deploy`, or pulling images with `containerd` will continue
to fail.
Given that other functionality is still broken with these registries, we consider
this fallback a _temporary_ solution, and will remove the fallback in an upcoming
major release.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Silvin Lubecki
Brian Goff
Sebastiaan van Stijn
Jim Lin
Arnaud Rebillout
Alexey Igrychev
DongGeon Lee
Christopher Svensson
Harald Albers
rochfeu
Tibor Vass
Chris Crone
Tibor Vass
Sebastiaan van Stijn
Chris Couzens
Morten Linderud