Try to improve the cache behavior for `ADD` and `COPY` commands.
Signed-off-by: Charles Chan <charleswhchan@users.noreply.github.com>
Upstream-commit: 08d5424c049dd67119cf0019ccb7fbc58bf27ec2
Component: engine
Trim excess from image. Based on the context, the email itself is sufficient.
Upstream-commit: a89370039a65f235d3dde5d36f20d0f463c615e9
Component: engine
This is fix for proper setup of nested containers cgroups.
Signed-off-by: Alexander Morozov <lk4d4@docker.com>
Upstream-commit: f0f261a899acf3c11d01c97e2503ec0ddb200232
Component: engine
Closes#14621
This one grew to be much more than I expected so here's the story... :-)
- when a bad port string (e.g. xxx80) is passed into container.create()
via the API it wasn't being checked until we tried to start the container.
- While starting the container we trid to parse 'xxx80' in nat.Int()
and would panic on the strconv.ParseUint(). We should (almost) never panic.
- In trying to remove the panic I decided to make it so that we, instead,
checked the string during the NewPort() constructor. This means that
I had to change all casts from 'string' to 'Port' to use NewPort() instead.
Which is a good thing anyway, people shouldn't assume they know the
internal format of types like that, in general.
- This meant I had to go and add error checks on all calls to NewPort().
To avoid changing the testcases too much I create newPortNoError() **JUST**
for the testcase uses where we know the port string is ok.
- After all of that I then went back and added a check during container.create()
to check the port string so we'll report the error as soon as we get the
data.
- If, somehow, the bad string does get into the metadata we will generate
an error during container.start() but I can't test for that because
the container.create() catches it now. But I did add a testcase for that.
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: 12b6083c8f82db7e5db4c683cfe20151731ea851
Component: engine
Current default basesize is 10G. Change it to 100G. Reason being that for
some people 10G is turning out to be too small and we don't have capabilities
to grow it dyamically.
This is just overcommitting and no real space is allocated till container
actually writes data. And this is no different then fs based graphdrivers
where virtual size of a container root is unlimited.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: 424d5e55a2f863b8eadab578e3ba647de09a4354
Component: engine
The check for the end of the loop was off by one which is why we saw
errors on the following inpsect() call instead of a timeout
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: c5c98c31a184837c7f5b1f43d8ef18a676a8bf30
Component: engine
Replaced github.com/docker/libcontainer with
github.com/opencontainers/runc/libcontaier.
Also I moved AppArmor profile generation to docker.
Main idea of this update is to fix mounting cgroups inside containers.
After updating docker on CI we can even remove dind.
Signed-off-by: Alexander Morozov <lk4d4@docker.com>
Upstream-commit: c86189d554ba14aa04b6314970d3699e5ddbf4de
Component: engine
Check if there is a plugin socket first under `/run/docker/plugins/NAME.sock`.
If there is no socket for a plugin, check `/etc/docker/plugins/NAME.spec` and
`/usr/lib/docker/plugins/NAME.spec` for spec files.
Signed-off-by: David Calavera <david.calavera@gmail.com>
Upstream-commit: 6c0795747b00589641eb34eb7adce05a56d8840f
Component: engine
This update includes removal of libcontainer dependency.
Signed-off-by: Alexander Morozov <lk4d4@docker.com>
Upstream-commit: b84ceb3d0ac53690f19cfc05f6b0e91e1998aa41
Component: engine
Closes#14675
Wasn't sure how far back I needed to go so I did just a few.
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: 081991c01e13c60af725bea91c4f5598dbcceaa9
Component: engine
