This dependency was temporarily forked, but
the fork was removed in db37a86d37431a1d82505cf6adc91a5d91dad146.
This patch removes the comment
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: fe877c2b959b60d953ad4b2d3eeda377add575a5
Component: engine
The name/ID relationships are maintained separately from the memdb and
can be out of sync from any particular memdb snapshot. If a container
does not exist in the memdb, we must accept this as normal and not fail
the listing. This is consistent with what the code used to do before
memdb was introduced.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: d257a63fb6a2ad0c2369981914544add389917bf
Component: engine
Recently, it's become necessary to build dynbinaries on certain
distributions, so make it easier for users to build dynbinaries. It
looks like this was just an oversight when we added dynbinary builds.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
Upstream-commit: c81255c9c0314b81ab27f6afd7646cdd259e6495
Component: engine
There have been some cases where umount, a device can be busy for a very
short duration. Maybe its udev rules, or maybe it is runc related races
or probably it is something else. We don't know yet.
If deferred removal is enabled but deferred deletion is not, then for the
case of "docker run -ti --rm fedora bash", a container will exit, device
will be deferred removed and then immediately a call will come to delete
the device. It is possible that deletion will fail if device was busy
at that time.
A device can't be deleted if it can't be removed/deactivated first. There
is only one exception and that is when deferred deletion is on. In that
case graph driver will keep track of deleted device and try to delete it
later and return success to caller.
Always make sure that device deactivation is synchronous when device is
being deleted (except the case when deferred deletion is enabled).
This should also take care of small races when device is busy for a short
duration and it is being deleted.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: 36cb6efebc599900b691e206fb9e99d3aa2fb9a3
Component: engine
Before this patch, if the plugin's `config.json` is successfully removed
but the main plugin state dir could not be removed for some reason (e.g.
leaked mount), it will prevent the daemon from being able to be
restarted.
This patches changes this to atomically remove the plugin such that on
daemon restart we can detect that there was an error and re-try. It also
changes the logic so that it only logs errors on restore rather than
erroring out the daemon.
This also removes some code which is now duplicated elsewhere.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 11cf394e5ea964636294a219872b188fe5bdf4dd
Component: engine
If a client is initialized without a specific
version set, version negotiation would not be
functional.
This patch changes the behavior to always
perform version negotation (if called), in
which case the "current" (maximum supported
API version) is used as a default.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 5975dc4b4b8a6fa2e0edd1f1b113e7f66dad732b
Component: engine
The NewVersionError checks if the client is using the API version
required for using a specific feature.
If the client is initialized without setting a specific version, an
error would be generated because it was not possible to compare
versions. However, a client without explicit version set is running
the latest supported version.
This patch changes the behavior to only generate an error if a version
was set.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: ff2ed1853099a210245814b4263ce1c92b14c153
Component: engine
If a container doesn't exist in the memdb, First will return nil, not an
error. This should be checked for before using the result.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Upstream-commit: c26b0cdfd1a026af88fcfbed9d3c3acdd6d171a0
Component: engine
With debug logging turned on, we currently log the base64-encoded secret
payload.
Change the middleware code to redact this. Since the field is called
"Data", it requires some context-sensitivity. The URI path is examined
to see which route is being invoked.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Upstream-commit: 3fbc352cbbce06cd3001d6b14b2b1ebcb4d42cd5
Component: engine
Split out a swarmCAOptions struct for options that are shared between
the ca and update commands.
Change the 'no trust root' message to an error.
Add some unit tests.
Signed-off-by: Daniel Nephin <dnephin@docker.com>
Upstream-commit: 81e9837859
Component: cli
In some cases a server may return an error on the ping response but
still provide version details. The client should use these values when
available.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 27ef09a46ffeb8ba42548de937b68351009f30ea
Component: engine
Because of argument order to assert, in case of fail, we'll get message
like:
... obtained string = "uid=100(test) gid=101(test)\n"
... expected string = "uid=100(test) gid=101(test) groups=101(test)\n"
But obtained string should be second one, not the first one. And
expected string should be first. Here's sample output from test above:
... Output: before restart 'uid=100(test) gid=101(test)
', after restart 'uid=100(test) gid=101(test) groups=101(test)
It's confusing, because expected order of strings in assertion is
reversed. What goes before restart - should be "expected string" and
what goes after - should be "obtained string".
Signed-off-by: Vitaly Ostrosablin <vostrosablin@virtuozzo.com>
Upstream-commit: 07cc701947533089fac5fea42e7d5a9a6ea1cfcc
Component: engine
Sebastiaan van Stijn
Aaron Lehmann
Arash Deshmeh
Aleksa Sarai
Brian Goff
Vivek Goyal
Daniel Nephin
Victor Vieux
Vincent Demeester
Harald Albers
Sebastiaan van Stijn
Boaz Shuster
Daniel Nephin
Kenfe-Mickaël Laventure
Vitaly Ostrosablin
lixiaobing10051267