In cases there are failures in task start, swarmkit might be trying to
restart the task again in the same node which might keep failing. This
creates a race where when a failed task is getting removed it might
remove the associated network while another task for the same service
or a different service but connected to the same network is proceeding
with starting the container knowing that the network is still
present. Fix this by reacting to `ErrNoSuchNetwork` error during
container start by trying to recreate the managed networks. If they
have been removed it will be recreated. If they are already present
nothing bad will happen.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
(cherry picked from commit 117cef5e9766d6ba228770c225e816c6afd16ff8)
Signed-off-by: Tibor Vass <tibor@docker.com>
Unlike `docker run -v..`, `docker service create --mount`
does not allow bind-mounting non-existing host paths.
This adds validation for the specified `source`, and
produces an error if the path is not found on the
host.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 84d5ab96ef33355e65f5c31210eb1777db372c52)
Signed-off-by: Tibor Vass <tibor@docker.com>
This is intended as a minor fix for 1.12.1 so that task creation doesn't
do unexpected things when the user supplies erroneous paths.
In particular, because we're currently using hostConfig.Binds to setup
mounts, if a user uses an absolute path for a volume mount source, or a
non-absolute path for a bind mount source, the engine will do the
opposite of what the user requested since all absolute paths are
treated as binds and all non-absolute paths are treated as named
volumes.
Fixes#25253
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
(cherry picked from commit 38f8b0eb10725c40fb3c7e0719accd240cd39e22)
Signed-off-by: Tibor Vass <tibor@docker.com>
Context cancellations were previously causing `Prepare` to fail
completely on re-entrant calls. To prevent this, we filtered out cancels
and deadline errors. While this allowed the service to proceed without
errors, it had the possibility of interrupting long pulls, causing the
pull to happen twice.
This PR forks the context of the pull to match the lifetime of
`Controller`, ensuring that for each task, the pull is only performed
once. It also ensures that multiple calls to `Prepare` are re-entrant,
ensuring that the pull resumes from its original position.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
(cherry picked from commit d8d71ad5b94d44a2778f2d8989424259cac94e9b)
Signed-off-by: Tibor Vass <tibor@docker.com>
Ensure that cancellation of a pull propagates rather than continuing to
container creation. This ensures that the `Prepare` method is properly
re-entrant.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
(cherry picked from commit d99c6b837ffd18ffe5bce801feb4936bf0edd2aa)
Signed-off-by: Tibor Vass <tibor@docker.com>
In the API:
`Writable` changed to `ReadOnly`
`Populate` changed to `NoCopy`
Corresponding CLI options updated to:
`volume-writable` changed to `volume-readonly`
`volume-populate` changed to `volume-nocopy`
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
(cherry picked from commit 56f3422468a0b43da7bae7a01762ce4f0a92d9ff)
Signed-off-by: Tibor Vass <tibor@docker.com>
In order to keep a little bit of "sanity" on the API side, validate
hostname only starting from v1.24 API version.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
(cherry picked from commit 6daf3d2a783fd042e870c8af8bbd19fc28989505)
Signed-off-by: Tibor Vass <tibor@docker.com>
Swarm was putting volume type mounts into the container config's
"Volumes" field, but really these need to go into "Binds".
"Volumes" is only for normal "-v /foo" volumes, not named volumes or
anything else.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
(cherry picked from commit 2bc2165cbf3e949921d1659f09841b5f008f590d)
Signed-off-by: Tibor Vass <tibor@docker.com>
This warning appears in the course of normal use of swarm mode. Since
it's meant more as an internal TODO than something which should be
exposed to a user, remove the log message.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
(cherry picked from commit 39c93cfb47783f2531ba44f062fd9a8b351d2224)
As described in our ROADMAP.md, introduce new Swarm management API
endpoints relying on swarmkit to deploy services. It currently vendors
docker/engine-api changes.
This PR is fully backward compatible (joining a Swarm is an optional
feature of the Engine, and existing commands are not impacted).
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Signed-off-by: Victor Vieux <vieux@docker.com>
Signed-off-by: Daniel Nephin <dnephin@docker.com>
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Tonis Tiigi
Jana Radhakrishnan
Sebastiaan van Stijn
Brian Goff
Stephen J Day
Nishant Totla
runshenzhu
Brian Goff
Vincent Demeester
Madhu Venugopal
Aaron Lehmann
bin liu
nick
tomwbarlow@gmail.com
Victor Vieux