Remove the non-OCI version of the configuration structure, and the
parent image ID, from the ImageData that libkpod returns.
At runtime, cri-o is only ever going to use the OCI configuration
(possibly converted from another format by the image library) when
setting up a container, so it can be confusing to display settings in
"kpod inspect" that might be discarded when we try to run a container.
Remove the non-OCI version of the configuration structure, and the
hard-coded Type field, from the ContainerData that libkpod returns.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
We already parse every image if there's a label filter so that we can
check against the filter, so when we do that, go ahead and read the
OCI-format configuration and inspection data as well, and use an image's
creation date as recorded in inspection data everywhere.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Avoid parsing metadata that the image library keeps in order to find an
image's top layer and creation date; instead, use the values which the
storage library now makes available, which will be correct once we merge
PR #654 or something like it.
Instead of assuming the last blob which was added for the image was the
manifest, read it directly and compute its digest ourselves.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Don't bother trying to find and parse the image's configuration blob
after we've already done it; just reuse the value. This frees us from
making the assumption that the last blob which was committed to local
storage was the image's configuration blob.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Parse the set of image names as tagged references, canonical references,
or repository names to which we add the default tag, and return them in
libkpod.ImageData reports.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Switch from using the lower-level storage APIs (accessing LayerStore,
ImageStore, and ContainerStore types directly) in favor of the
higher-level ones that take care of synchronization and locking for us.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
