In NewContainer if a SnapshotKey is used and the spec has
a mountLabel specified, that mountLabel should be used to mount
the rootfs.
Signed-off-by: Darren Shepherd <darren@rancher.com>
TestImageIsUnpacked will unpacked docker.io/library/busybox:latest with
linux/amd64 platform. If the TestImageUsage doesn't wait for cleanup
finish (snapshotter is cleanup by gc asynchronously) and fetch image,
the Usage(ctx) will get 10767844 bytes(manifestUsage + snapshotUsage).
However, the manifestUsage is 9466142 bytes. That is why we got the
error:
```
Expected actual usage to equal manifest reported usage of 9466142:
got 10767844
```
This commit is to make sure that the image has been cleanup fully.
Signed-off-by: Wei Fu <fuweid89@gmail.com>
When there is timeout or cancel for create container, killShim will fail
because of canceled context. The shim will be dangling and unmanageable.
Need to use new context to do cleanup.
Signed-off-by: Wei Fu <fuweid89@gmail.com>
The builtins_cri_linux.go file only being included for _linux builds which
means that the builds for Windows do not contain the CRI plugin. This can
be disabled for either platform with the no_cri tag.
Signed-off-by: Justin Terry (SF) <juterry@microsoft.com>
The background context aovids shim blocking when the ctx is cancelled
unexpectedly during shim start. But if the shim exits unexpectedly
before opening the pipe, the fd will never be closed.
`onCloseWithShimLog` makes sure that the shim log fd is closed properly
once the shim disconnects.
Signed-off-by: Li Yuxuan <liyuxuan04@baidu.com>
These are text files so there's no reason these files are executable,
unless I'm missing something? Maybe it's something that doesn't show on
a Windows filesystem, only on Linux or macOS, hence nobody noticed?
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>
When we call `go get -d -v
github.com/kubernetes-incubator/cri-tools/...` which repos has been
moved to `github.com/kubernetes-sigs/cri-tools`, `go get` will create
package `github.com/kubernetes-sigs/cri-tools`.
```
go get -d -v github.com/kubernetes-incubator/cri-tools/...
github.com/kubernetes-incubator/cri-tools (download)
github.com/kubernetes-sigs/cri-tools (download)
```
According to old version of `github.com/kubernetes-incubator/cri-tools`
Makefile, if there is no `github.com/kubernetes-sigs/cri-tools` package,
it will create softlink self to `github.com/kubernetes-sigs/cri-tools`.
But `go get` will create `github.com/kubernetes-sigs/cri-tools` and
there is no softlink. Therefore, the critools are always latest one, not
specific version.
So, use `github.com/kubernetes-sigs/cri-tools` will be better and save
traffic from `go get`.
Signed-off-by: Wei Fu <fuweid89@gmail.com>
Don't rely on /proc/cpuinfo denoting a 64-bit ARMv8 processor if the
runtime detected GOARCH == arm. This allows aarch64 32-bit userspace
distros to run containers properly via a 32-bit runtime.
Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com>
The pkg/store errors are duplicated errors of NotFound and AlreadyExist from
containerd's errdefs package and thus do not properly serialize when running
errdefs.ToGRPC on them. CRI runs this function on every return from a CRI
method so the conversion fails if there is a cache miss from the store caches
for containers or sandboxes. This change verifies that the errors are properly
converted to their gRPC values.
Signed-off-by: Justin Terry (VM) <juterry@microsoft.com>
