libmage: Exists: catch corrupted images #612
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: vrothberg The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@saschagrunert @Luap99 @rhatdan PTAL I will create yet another backport and get that into Podman v3.2. |
vrothberg
changed the title
While various execution paths in libimage already handle corrupted images, `(*Runtime).Exists()` did not and would list an image to exist in the storage even if it is corrupted. Some corruptions can only be detected when accessing the individual data. A reliable way of accessing such data is to inspect an image. Hence, an image will only be listed to exist if a) it has been found and b) can be inspected. If the inspection fails, the image will be reported to not exists but without an error. That allows for users of libimage to properly recover and repull. Further, add a new unit tests that forces a data corruption and gradually recovers from it. Podman will now behave as follows: ``` $ ./bin/podman run -d --rm nginx ls ERRO[0000] Image nginx exists in local storage but may be corrupted: layer not known ERRO[0000] Looking up nginx in local storage: layer not known Resolved "nginx" as an alias (/home/vrothberg/.cache/containers/short-name-aliases.conf) Trying to pull docker.io/library/nginx:latest... Getting image source signatures Copying blob 596b1d696923 skipped: already exists Copying blob 30afc0b18f67 skipped: already exists Copying blob febe5bd23e98 skipped: already exists Copying blob 69692152171a skipped: already exists Copying blob 8283eee92e2f skipped: already exists Copying blob 351ad75a6cfa done Copying config d1a364dc54 done Writing manifest to image destination Storing signatures 56b65883c3c32b67277bcc173bd9f26c27cbbdbc6d3aacf6c552be796eb7a337 ``` Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
vrothberg
force-pushed
the
image-corruption
branch
from
9f930a4
to
964b002
Compare
|
LGTM |
|
@Luap99: changing LGTM is restricted to collaborators In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@vrothberg @rhatdan Mind adding me to OWNERS file for c/common? |
|
/lgtm |
|
@vrothberg: you cannot LGTM your own PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
|
/lgtm |
While various execution paths in libimage already handle corrupted
images,
(*Runtime).Exists()did not and would list an image to existin the storage even if it is corrupted.
Some corruptions can only be detected when accessing the individual
data. A reliable way of accessing such data is to inspect an image.
Hence, an image will only be listed to exist if a) it has been found
and b) can be inspected. If the inspection fails, the image will be
reported to not exists but without an error. That allows for users
of libimage to properly recover and repull.
Further, add a new unit tests that forces a data corruption and
gradually recovers from it.
Podman will now behave as follows:
Signed-off-by: Valentin Rothberg rothberg@redhat.com