summaryrefslogtreecommitdiff
path: root/libpod/image/layer_tree.go
Commit message (Collapse)AuthorAge
* migrate Podman to containers/common/libimageValentin Rothberg2021-05-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Migrate the Podman code base over to `common/libimage` which replaces `libpod/image` and a lot of glue code entirely. Note that I tried to leave bread crumbs for changed tests. Miscellaneous changes: * Some errors yield different messages which required to alter some tests. * I fixed some pre-existing issues in the code. Others were marked as `//TODO`s to prevent the PR from exploding. * The `NamesHistory` of an image is returned as is from the storage. Previously, we did some filtering which I think is undesirable. Instead we should return the data as stored in the storage. * Touched handlers use the ABI interfaces where possible. * Local image resolution: previously Podman would match "foo" on "myfoo". This behaviour has been changed and Podman will now only match on repository boundaries such that "foo" would match "my/foo" but not "myfoo". I consider the old behaviour to be a bug, at the very least an exotic corner case. * Futhermore, "foo:none" does *not* resolve to a local image "foo" without tag anymore. It's a hill I am (almost) willing to die on. * `image prune` prints the IDs of pruned images. Previously, in some cases, the names were printed instead. The API clearly states ID, so we should stick to it. * Compat endpoint image removal with _force_ deletes the entire not only the specified tag. Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* podman rmi: handle corrupted storage betterValentin Rothberg2021-03-01
| | | | | | | | | | | | | | | The storage can easily be corrupted when a build or pull process (or any process *writing* to the storage) has been killed. The corruption surfaces in Podman reporting that a given layer could not be found in the layer tree. Those errors must not be fatal but only logged, such that the image removal may continue. Otherwise, a user may be unable to remove an image. [NO TESTS NEEDED] as I do not yet have a reliable way to cause such a storage corruption. Reported-in: https://github.com/containers/podman/issues/8148#issuecomment-787598940 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* make layer-tree lookup errors non-fatalValentin Rothberg2021-02-12
| | | | | | | | | | | | | | | | | | | | | Internally, Podman constructs a tree of layers in containers/storage to quickly compute relations among layers and hence images. To compute the tree, we intersect all local layers with all local images. So far, lookup errors have been fatal which has turned out to be a mistake since it seems fairly easy to cause storage corruptions, for instance, when killing builds. In that case, a (partial) image may list a layer which does not exist (anymore). Since the errors were fatal, there was no easy way to clean up and many commands were erroring out. To improve usability, turn the fatal errors into warnings that guide the user into resolving the issue. In this case, a `podman system reset` may be the approriate way for now. [NO TESTS NEEDED] because I have no reliable way to force it. [1] https://github.com/containers/podman/issues/8148#issuecomment-778253474 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* make image parent check more robustValentin Rothberg2020-09-07
| | | | | | | | Follow up on issue #7444 and make the parent checks more robust. We can end up with an incoherent storage when, for instance, a build has been killed. Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* image list: speed upValentin Rothberg2020-08-07
Listing images has shown increasing performance penalties with an increasing number of images. Unless `--all` is specified, Podman will filter intermediate images. Determining intermediate images has been done by finding (and comparing!) parent images which is expensive. We had to query the storage many times which turned it into a bottleneck. Instead, create a layer tree and assign one or more images to nodes that match the images' top layer. Determining the children of an image is now exponentially faster as we already know the child images from the layer graph and the images using the same top layer, which may also be considered child images based on their history. On my system with 510 images, a rootful image list drops from 6 secs down to 0.3 secs. Also use the tree to compute parent nodes, and to filter intermediate images for pruning. Signed-off-by: Valentin Rothberg <rothberg@redhat.com>