Right now container runtimes have no way to provide additional context
to the pull errors. We now loosen the constraints and check for
additional messages after the actual CRI errors, which allows to enrich
the verbosity of the warning events, for example:
```
Warning Failed 2s (x3 over 43s) kubelet Failed to pull image "localhost:5000/foo": RegistryUnavailable: pinging container registry localhost:5000: Get "http://localhost:5000/v2/": dial tcp [::1]:5000: connect: connection refused
```
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
This allows container runtimes to propagate an image signature
verification error through the CRI and display that to the end user
during image pull. There is no other behavioral difference compared to a
regular image pull failure.
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
This patch fixes a regression introduced by
https://github.com/kubernetes/kubernetes/pull/51751 in the CRI
interface.
That commit actually changed a unit test where we were previously *not*
assuming anything about an image name.
Before that commit, if you send the image "busybox" through the CRI,
the container runtime receives "busybox". After that patch the
container runtime gets "docker.io/library/busybox".
While that may be correct for the internal kube dockershim, in the CRI
we must not assume anything about image names. The ImageSpec is not
providing any spec around the image so the container runtime should
just get the raw image name from the pod spec. Every container runtime
can handle image names the way it wants. The "docker.io" namespace is
not at all "standard", CRI-O is not following what the docker UI say
since that's the docker UI. We should not focus the CRI on wrong UI
design, especially around a default namespace.
ImageSpec is not standardized yet:
https://github.com/kubernetes/kubernetes/issues/46255 and
https://github.com/kubernetes/kubernetes/issues/7203
This is something which should land in 1.9 as well since the regression
is from 1.8.
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
Despite its name, AssertCalls() does not assert anything. It returns an
error that must be checked. This was causing false negatives for
a handful of unit tests.
This allows runtimes in different packages (dockertools, rkt, kuberuntime) to
share the same logic. Before this change, only dockertools support this
feature. Now all three packages support image pull throttling.
