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>
Make getStore() take a config struct from which it pulls the store
options, then update the kpod commands so that they call getConfig()
and pass the config into getStore()
Signed-off-by: Ryan Cole <rcyoalne@gmail.com>
This update allows the creation of docker-archive files when the
destination does not exists or is empty. kpod save needs this functionality.
Signed-off-by: Dan Walsh <dwalsh@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>
github.com/containers/image.FromUnparsedImage() "takes ownership" of the
UnparsedImage that we pass to it, so we shouldn't also Close() the
UnparsedImage ourselves after we've wrapped it up in an Image object.
Since creating an Image is the only thing we do with the UnparsedImage
after creating it from a SourceImage, just use the FromSource() function
to handle both steps at once.
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>
Add notes to README.md about needing to install ostree-devel, or
libostree-dev, or building ostree from source.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Bump containers/image (pulling in its new dependency on ostree-go),
containers/storage, and updated image-spec.
This pulls in the OCI v1.0 specifications and code that allows us to
support 1.0 images.
Signed-off-by: Dan Walsh <dwalsh@redhat.com>
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
update libkpod's New() function to use a config struct, and update
server.New() to call into libkpod.New()
Signed-off-by: Ryan Cole <rcyoalne@gmail.com>
During my testing in OpenShift I've noticed that conmon leaves some
zombies processes. The reason is that we are using
PR_SET_CHILD_SUBREAPER in conmon and runC forks a new process (runc
init) each time we start a container. Using g_child_watch_add only on
the main runc process and on the container process is not enough as we
do not cleanup any other zombie process.
Since glib doesn't allow to catch SIGCHLD and to better integrate in the
existing code, catch it with signal(2) then raise a SIGUSR1 that glib
handles.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
