A task whose image cannot be pulled is rejected outright when the registry
answers with an "unauthorized" error, even when the image is already present
on the node. A service created without registry credentials carries no auth in
its spec and cannot have its digest resolved, so its tasks always attempt an
unauthenticated pull; on nodes that already hold the image those tasks are
rejected instead of started.
Tolerating a failed pull when the image is available locally is long-standing
behaviour, described in the comment above the check, and what the executor did
for every pull error before a7cf7eac0a ("fix: propagate registry auth error in
swarm image pull").
Keep reporting the pull failure, as it is far more useful than the "No such
image" the container create would otherwise produce, but only when the image
really is unavailable. Whether a task can run should not depend on how the
registry error happened to be classified, and that classification is not
consistent: the same registry 401 surfaces as ErrUnauthenticated from the
graphdriver pull path, as ErrNotFound from the containerd image store (via
docker.ErrInvalidAuthorization), and as ErrUnknown when the failure happens
while fetching a token, since the error is then a *url.Error that
translatePullError does not classify. The check therefore only fires for some
combinations of image store and registry.
The test needs DOCKER_SERVICE_PREFER_OFFLINE_IMAGE=0 on the daemon under test:
internal/testutil/daemon sets it to 1, which makes the executor skip the pull
altogether.
Signed-off-by: Sopho Merkviladze <smerkviladze@mirantis.com>
When a worker pull fails with unauthorized, the error was being
swallowed and replaced with misleading 'No such image' message.
Fix error propagation so the actual cause is reported.
Signed-off-by: Md_Mushfiqur Rahim <20mahin20201@gmail.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Follow-up to 494677f93f, which added
the aliases, but did not yet replace our own use of the nat types.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These comments were added to enforce using the correct import path for
our packages ("github.com/docker/docker", not "github.com/moby/moby").
However, when working in go module mode (not GOPATH / vendor), they have
no effect, so their impact is limited.
Remove these imports in preparation of migrating our code to become an
actual go module.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This error implemented the Causer interface, but did not implement
the go1.13 unwrapper, which could prevent errors from being matched.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This moves the `ContainerJSONBase`, `ContainerJSON` and `ContainerNode`
types to the api/types/container package and deprecates the old location.
- `ContainerJSONBase` was renamed to `InspectBase`
- `ContainerJSON` was rnamed to `InspectResponse`
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
While working on this file, I noticed the `isContainerCreateNameConflict`,
`isUnknownContainer`, and `isStoppedContainer` utilities, which are used
to perform error-type detection through string-matching.
These utilities were added in 534a90a993,
as part of the initial implementation of the Swarm executor in Docker.
At that time, the Docker API client did not return typed errors, and
various part of the code depended on string matching, which is brittle,
and it looks like `isContainerCreateNameConflict` at least is already
broken since c9d0a77657, which changed
the error-message.
Starting with ebcb7d6b40, we use typed
errors through the errdefs package, so we can replace these utilities:
The `isUnknownContainer` utility is replace by `errdefs.IsNotFound`,
which is returned if the object is not found. Interestingly, this utility
was checking for containers only (`No such container`), but was also
used for an `removeNetworks` call. Tracking back history of that use to
verify if it was _intentionally_ checking for a "container not found"
error;
- This check added in the initial implementation 534a90a993
- Moved from `controller.Remove` to `container.Shutdown` to make sure the
sandbox was removed in 680d0ba4ab
- And finally touched again in 70fa7b6a3f,
which was a follow-up to the previous one, and fixed the conditions
to prevent returning early before the network was removed.
None of those patches mention that these errors are related to containers,
and checking the codepath that's executed, we can only expect a
`libmetwork.ErrNoSuchNetwork` to be returned, so this looks to have been
a bug.
The `isStoppedContainer` utility is replaced by `errdefs.IsNotModified`,
which is the error (status) returned in situations where the container
is already stopped; https://github.com/moby/moby/blob/caf502a0bc44c19b4e1dde50428de07ff756a8d3/daemon/stop.go#L30-L35
This is the only
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Define consts for the Actions we use for events, instead of "ad-hoc" strings.
Having these consts makes it easier to find where specific events are triggered,
makes the events less error-prone, and allows documenting each Action (if needed).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
After moving libnetwork to this repo, we need to update all the import
paths for libnetwork to point to docker/docker/libnetwork instead of
docker/libnetwork.
This change implements that.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Make sure adapter.removeNetworks executes during task Remove
adapter.removeNetworks was being skipped for cases when
isUnknownContainer(err) was true after adapter.remove was executed
This fix eliminates the nil return case forcing the function
to continue executing unless there is a true error
Fixes https://github.com/moby/moby/issues/39225
Signed-off-by: Arko Dasgupta <arko.dasgupta@docker.com>
Blocks the execution of tasks during the Prepare phase until there
exists an IP address for every overlay network in use by the task. This
prevents a task from starting before the NetworkAttachment containing
the IP address has been sent down to the node.
Includes a basic test for the correct use case.
Signed-off-by: Drew Erny <drew.erny@docker.com>
Since Go 1.7, context is a standard package. Since Go 1.9, everything
that is provided by "x/net/context" is a couple of type aliases to
types in "context".
Many vendored packages still use x/net/context, so vendor entry remains
for now.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
The error type libnetwork.ErrNoSuchNetwork is used in the controller
to retry the network creation as a managed network though the manager.
The change of the type was breaking the logic causing the network to
not being created anymore so that no new container on that network
was able to be launched
Added unit test
Signed-off-by: Flavio Crisciani <flavio.crisciani@docker.com>
Having a map per log entry seemed heavier than necessary. These
attributes end up being sorted and serialized, so storing them in a map
doesn't add anything (there's no random access element). In SwarmKit,
they originate as a slice, so there's an unnecessary conversion to a map
and back.
This also fixes the sort comparator, which used to inefficiently split
the string on each comparison.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
This patch consolidates the two WaitStop and WaitWithContext methods
on the container.State type. Now there is a single method, Wait, which
takes a context and a bool specifying whether to wait for not just a
container exit but also removal.
The behavior has been changed slightly so that a wait call during a
Created state will not return immediately but instead wait for the
container to be started and then exited.
The interface has been changed to no longer block, but instead returns
a channel on which the caller can receive a *StateStatus value which
indicates the ExitCode or an error if there was one (like a context
timeout or state transition error).
These changes have been propagated through the rest of the deamon to
preserve all other existing behavior.
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
URL query encode log details, so that characters like spaces don't make
log parsing ambiguous. Add a helper function to parse these details to a
map, if needed
Add support for details on service logs
Signed-off-by: Drew Erny <drew.erny@docker.com>
Fixed an issue where service logs would hang if the container backing a
task was deleted by not waiting for containers to be ready if we're not
following logs.
Signed-off-by: Drew Erny <drew.erny@docker.com>