Removed unnecessary RUN statements and combined some of the RUN statement into a single line.
The runtime performance is seen as follows:
pre-change:
PASS: docker_cli_build_test.go:3826: DockerSuite.TestBuildUsersAndGroups
63.074s
post-change:
PASS: docker_cli_build_test.go:3826: DockerSuite.TestBuildUsersAndGroups
49.698s
Signed-off-by: Anil Belur <askb23@gmail.com>
Upstream-commit: deeb5c95e2eaa58d4490cb126839b8bc41e5ba08
Component: engine
This fixes docker save when the daemon was launched from a remote
PowerShell session.
Signed-off-by: John Starks <jostarks@microsoft.com>
Upstream-commit: 845dce846528f1ab7f6dc43b760b32aee666d9ac
Component: engine
Correct creation of a non-existing WORKDIR during docker build to use
remapped root uid/gid on mkdir
Docker-DCO-1.1-Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com> (github: estesp)
Upstream-commit: 799a6b94ee661022d66f88a009ff58f08eb5a2c3
Component: engine
It'll weaken this test case, and the flaky test is resolved
by another commit in this PR.
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
Upstream-commit: 021a12ef1b96ebee852173212d9de6b0a6285f92
Component: engine
I can reproduce this easily on one of my servers,
`docker exec -ti my_cont ls` will not print anything,
without `-t` it acts normally.
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
Upstream-commit: a444b5f60c75bdac82c9a7126738c210e2ccf941
Component: engine
Fixes: #20709
As discussed in the issue, we need refine the message to
help user more understood, what happened for non-exist image.
Signed-off-by: Kai Qiang Wu(Kennan) <wkqwu@cn.ibm.com>
Upstream-commit: ed231d409501d1e496fbe2b2e31a279eb2998cf2
Component: engine
This fix tries to improve the time to run TestRunUnshareProc
in #19425.
In this fix goroutines are used to run test cases in parallel to
prevent the test from taking a long time to run.
As the majority of the execution time in the tests is from
multiple executions of 'docker run' and each of which takes
several seconds, parallel executions improve the test time.
Since each 'docker run' is independent, the purpose of the
test is not altered in this fix.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 526c2fe942107908fe324db2ecceee14b69cb191
Component: engine
Once thin pool gets full, bad things can happen. Especially in case of xfs
it is possible that xfs keeps on retrying IO infinitely (for certain kind
of IO) and container hangs.
One way to mitigate the problem is that once thin pool is about to get full,
start failing some of the docker operations like pulling new images or
creation of new containers. That way user will get warning ahead of time
and can try to rectify it by creating more free space in thin pool. This
can be done either by deleting existing images/containers or by adding more
free space to thin pool.
This patch adds a new option dm.min_free_space to devicemapper graph
driver. Say one specifies dm.min_free_space=10%. This means atleast
10% of data and metadata blocks should be free in pool before new device
creation is allowed, otherwise operation will fail.
By default min_free_space is 10%. User can change it by specifying
dm.min_free_space=X% on command line. A value of 0% will disable the
check.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: 2e222f69b3486cf20039525a882ae4153b52f92c
Component: engine
The documentation for Docker 1.10.2 (API version 1.22) mentions under
the "Create a container"[1] section that `HostConfig.Binds` can be given
a "container path" which will automatically "create a new volume for the
container."
I interpreted this to mean it that the following two commands should
have the same net result:
# Create container with data volume via REST API
curl --unix-socket /var/run/docker.sock -XPOST \
http://localhost/containers/create \
-H"Content-Type: application/json" \
-d'{
"Image": "<image-id>",
...
"HostConfig": {
"Binds": [
"/some/data/volume"
]
}
}'
# Create container with data volume via CLI
docker create -v /some/data/volume <image-id> <command>
However, this turned out not the be the case, as the former would create
a mount with no source and no corresponding volume:
...
"Mounts": [
{
"Source": "",
"Destination": "/some/data/volume",
"Driver": "local",
"Mode": "",
"RW": true,
"Propagation": "rprivate"
}
],
...
"Config": {
...
"Volumes": null,
...
}
...whereas the latter would create a volume and mount it:
...
"Mounts": [
{
"Name": "9b38af46d6..."
"Source": "/var/lib/docker/volumes/9b38af46d6.../_data",
"Destination": "/some/data/volume",
"Driver": "local",
"Mode": "",
"RW": true,
"Propagation": ""
}
],
...
"Config": {
...
"Volumes": {
"/some/data/volume": {}
},
...
}
However, if you instead specify the data volume via the `Volumes` key,
then it works as expected, e.g.
curl --unix-socket /var/run/docker.sock -XPOST \
http://localhost/containers/create \
-H"Content-Type: application/json" \
-d'{
"Image": "...",
...
"Volumes": {"/some/data/volume": {}}
}'
...will create a data volume and mount it.
Thus the documentation is either incorrect, or this is a bug and the
ability to create a data volume via `HostConfig.Binds` does not
work as advertised for API version 1.22 (and likely others).
I concluded that the documentation was incorrect. Since I've only
verified this behavior for Docker 1.10.2, I updated the docs for
API versions 1.22 and 1.23, but this may apply to other versions as
well.
[1] https://docs.docker.com/engine/reference/api/docker_remote_api_v1.22/#create-a-container
Signed-off-by: Shane da Silva <shane@dasilva.io>
Upstream-commit: 62fef18d69be7d8c5338fe5a471966dc1e6d68f7
Component: engine
This fixes commit on Windows post-TP4 due to a small change
in behavior in the ExportLayer API.
Signed-off-by: John Starks <jostarks@microsoft.com>
Upstream-commit: 53b8b8f0581b4ecb04a2aa4a195fd805f81bfa8c
Component: engine
On 32 bit x86 this is a multiplexing syscall for the system V
ipc syscalls such as shmget, and so needs to be allowed for
shared memory access for 32 bit binaries.
Fixes#20733
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Upstream-commit: 31410a6d79fc4ea6fa496636015bf9f53c1c8b14
Component: engine
allencloud
Phil Estes
Sebastiaan van Stijn
Anil Belur
Zhang Wei
Antonio Murdaca
Alessandro Boch
Tianon Gravi
David Calavera
Brian Goff
John Starks
Tibor Vass
Jessica Frazelle
Alexander Morozov
Phil Estes
trishnaguha
Antonio Murdaca
Wen Cheng Ma
Qiang Huang
Kai Qiang Wu(Kennan)
Riyaz Faizullabhoy
Yong Tang
Vivek Goyal
Ralle
Mrunal Patel
Vincent Demeester
Shane da Silva
Ziming Dong
Jess Frazelle
Justin Cormack
Doug Davis