jm.ID is already checked in the outer "if",
so theres no reason to check it again here.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 7a6f5d9b3186de2116686d5e2c40eff673dae6ec
Component: engine
aufs kernel module creates whiteout files on upper layer delete (and
other situations) and those files already are 'translated' regarding
ownership in host terms (e.g. they are already "0:0" owned), so when
these layers are copied around with pkg/archive we don't want to try and
translate these files regarding ownership.
Docker-DCO-1.1-Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com> (github: estesp)
Upstream-commit: 1626c9dae0f285185e3ef4c1e2be55a807e8c0ed
Component: engine
Adds ppc64le image to the Dockerfile,
should be with 03fc212b6d6c2b3ecff42f33b7b3a7181043b09e
Signed-off-by: Christopher Jones <tophj@linux.vnet.ibm.com>
Upstream-commit: a796eea2b526743d391ba2ea1f4a0bb03eb94bfe
Component: engine
This removes sections from the maintainers file
that have been moved to the https://github.com/docker/opensource
repository.
Also replaces spaces for tabs for consistency (yay ocd).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: a848c5e78214cb0f00bbd01bf069169ae90b0908
Component: engine
* Wording around what docker-machine does since the phrase "Docker virtual machine" can cause some confusion.
* Docker Machine isn't a distro in and of itself. It still uses boot2docker as the distro.
* Remove "virtualization" keywords.
Signed-off-by: Jeff Anderson <jeff@docker.com>
Upstream-commit: 0d1c5193b389052f11d77ca576f7dbb49b601135
Component: engine
All underlay dirs need proper remapped ownership. This bug was masked by the
fact that the setupInitLayer code was chown'ing the dirs at startup
time. Since that bug is now fixed, it revealed this permissions issue.
Docker-DCO-1.1-Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com> (github: estesp)
Upstream-commit: 191cefbaca45ba86341379d09d2f75d5fc1868fb
Component: engine
This test was directly comparing lines of output from "docker images".
Sometimes, when busybox had been pushed to the hub recently, the
relative creation times would differ like this:
... obtained []string = []string{"busybox", "latest", "d9551b4026f0", "27", "minutes", "ago", "1.113", "MB"}
... expected []string = []string{"busybox", "latest", "d9551b4026f0", "26", "minutes", "ago", "1.113", "MB"}
Fixing by removing the time-since-creation fields from the comparison.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Upstream-commit: d17669999fff55219f5ed236f00fdf8a08d09304
Component: engine
ContinueOnError assumes that something of type errcode.Errors contains
at least one error. This is generally true, but might not be true if the
remote registry returns an empty error body or invalid JSON. Add the
bounds check, and in the case where it fails, allow fallbacks to v1.
Fixes#18481
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Upstream-commit: 1ebfa299545e5c2273ce449d72b10745b9e38087
Component: engine
Each plug-in operates as a separate service, and registers with Docker
through general (plug-ins API)
[https://blog.docker.com/2015/06/extending-docker-with-plugins/]. No
Docker daemon recompilation is required in order to add / remove an
authentication plug-in. Each plug-in is notified twice for each
operation: 1) before the operation is performed and, 2) before the
response is returned to the client. The plug-ins can modify the response
that is returned to the client.
The authorization depends on the authorization effort that takes place
in parallel [https://github.com/docker/docker/issues/13697].
This is the official issue of the authorization effort:
https://github.com/docker/docker/issues/14674
(Here)[https://github.com/rhatdan/docker-rbac] you can find an open
document that discusses a default RBAC plug-in for Docker.
Signed-off-by: Liron Levin <liron@twistlock.com>
Added container create flow test and extended the verification for ps
Upstream-commit: 75c353f0ad73bd83ed18e92857dd99a103bb47e3
Component: engine
The server-side portion of "docker images" sorts the images it returns
by creation timestamp so the list keeps a consistent order. However, it
does not sort the RepoTags and RepoDigests lists that each image carries
along with it. Since items in these lists are populated from a map,
their order will vary. If the user has a collection of tags which point
to overlapping IDs, for example tags that point to the same images on
different registries, the order will fluctuate between invocations of
"docker images". This can be disorienting with a long list of images.
Sort these references at the tag store level, so that the tag store's
References call always returns references in a lexically sorted order.
As well as giving the tag store more deterministic behavior, doing it at
this level simplifies the tag store unit tests.
Do the same for the ReferencesByName call. This will make push-all-tags
iterate over the tags in a consistent order.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Upstream-commit: 6e37b622d39591038a4907ee7171a359076bc1db
Component: engine
Since seccomp is still a configurable build-tag, add a requirements
entry for seccomp, as well as move seccomp tests to "_unix" given it
won't be applicable to other platforms at this time.
Docker-DCO-1.1-Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com> (github: estesp)
Upstream-commit: 0433e3891532a9783b77d6b02c041bab359b0d91
Component: engine
In the existing code, "diff" has function scope and the value from the
previous iteration may be used if it is not reset. This appears to be an
oversight. This commit changes its scope to the for loop body.
One confusing point is that the cursor movement escape sequences appear
to be necessary even if the requested movement is 0. I haven't been able
to figure out why this makes a difference.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Upstream-commit: 59df2adc071e0186ccd0ba7ea9387142e168d735
Component: engine
When we handle a message that isn't tracked in the "line" map (for
example, one with no ID), clear the line map. This means we won't update
lines that were part of a previous, completed set of operations when
doing something like pull -a. It also has the beneficial side effect
of avoiding terminal glitching in these types of situations, since
messages that don't get tracked in the "line" map cause the count of the
number of lines to get out of sync.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Upstream-commit: fc41d393946e6da59792da9ed6e5ab8ed6f58814
Component: engine
