buildStages now tracks the imageID and runConfig for a build stage
imageMounter tracks image mounts so they can released when the build ends.
Signed-off-by: Daniel Nephin <dnephin@docker.com>
Upstream-commit: 6c28e8edd5f047d5b1438f773d49882f28d7a006
Component: engine
Removes 3 methods from the builder.Backend interface
Remove the coupling between imageContexts, imageMounts and the builder.
Signed-off-by: Daniel Nephin <dnephin@docker.com>
Upstream-commit: b3bc7b28d09138a37ab5476eb46dfe74f8984f18
Component: engine
Allows storing key under any directory. In the case where the
"/etc/docker" directory is not preserved, this file can be
specified to a location where it will be preserved to ensure
the ID does not change across restarts.
Note this key is currently only used today to generate the ID
used in Docker info and for manifest schema v1 pushes. The key
signature and finger on these manifests are not checked or
used any longer for security, deprecated by notary.
Removes old key migration from a pre-release of Docker which put
the key under the home directory and was used to preserve ID used
for swarm v1 after the file moved.
closes#32135
Signed-off-by: Derek McGowan <derek@mcgstyle.net>
Upstream-commit: e428c824c35e85a02fffee592b79ab7db1a0c4d2
Component: engine
objects into the REST API responses. In the CLI, display only
whether the nodes' TLS info matches the cluster's TLS info, or
whether the node needs cert rotation.
Signed-off-by: Ying Li <ying.li@docker.com>
Upstream-commit: 64cccedbce86542fc9289ad9cca1dd758f2f21c2
Component: engine
Actually look inside the container to see if the secret data is present
and correct. Test absolute paths, relative paths, and just a basename.
Test the scenario where a service references the same secret under
different targets.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Upstream-commit: 0da7bd0314a61919428fe036660b822b0bf22d35
Component: engine
This prevents targets with the same basename from colliding.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Upstream-commit: 37ce91ddd60e50a8bcd7ac3a7ba858f94c28c51e
Component: engine
This adds support to specify custom container paths for secrets.
Signed-off-by: Evan Hazlett <ejhazlett@gmail.com>
Upstream-commit: 67d282a5c95ca1d25cd4e9c688e89191f662d448
Component: engine
Fixes#33101
This syncs up the OPOST changes for mkraw on the tty
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Upstream-commit: 6a96049ddf24e8b929f04c7df587e66ae4d11566
Component: engine
All LVM actions in the devicemapper library are asyncronous, involving a call to
a task enqueue function (dm_run_task) and a wait on a resultant udev event
(UdevWait). Currently devmapper.go defers all calls to UdevWait, which discards
the return value. While it still generates an error message in the log (if
debugging is enabled), the calling thread is still allowed to continue as if no
error has occured, leading to subsequent errors, and significant confusion when
debugging, due to those subsequent errors. Given that there is no risk of panic
between the task submission and the wait operation, it seems more reasonable to
preform the UdevWait inline at the end of any given lvm action so that errors
can be caught and returned before docker can continue and create additional
failures.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Upstream-commit: 5206d45e70512f5fc06006047fb67b2f478b304d
Component: engine
Currently, the devicemapper library sets cookies to correlate wait operations,
which must be unique (as the lvm2 library doesn't detect duplicate cookies).
The current method for cookie generation is to take the address of a cookie
variable. However, because the variable is declared on the stack, execution
patterns can lead to the cookie variable being declared at the same stack
location, which results in a high likelyhood of duplicate cookie use, which in
turn can lead to various odd lvm behaviors, which can be hard to track down
(object use before create, duplicate completions, etc). Lets guarantee that the
cookie we generate is unique by declaring it on the heap instead. This
guarantees that the address of the variable won't be reused until such time as
the UdevWait operation completes, and drops its reference to it, at which time
the gc can reclaim it.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Upstream-commit: edd1c9e3255ddd80c97313bd596812dbb3470a5b
Component: engine
If a wait event fails when preforming a devicemapper operation, it would be good
to know, in addition to the cookie that its waiting on, we reported the error
that was reported from the lvm2 library.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Upstream-commit: 547510fb554bb77aa7f09efd46361306152b9d55
Component: engine