The image's canonical reference is a name with a digest of the image's
manifest, so in imageService.ImageStatus() and
imageService.ListImages(), divide the image's name list into tagged and
digested values, and if we have names, add canonical versions.
In Server.ContainerStatus(), return the image name as it was given to us
as the image, and the image digested reference as the image reference.
In Server.ListImages(), be sure to only return tagged names in the
RepoTags field. In Server.ImageStatus(), also return canonical
references in the RepoDigests field.
In Server.PullImage(), be sure that we consistently return the same
image reference for an image, whether we ended up pulling it or not.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
The image's canonical reference is a name with a digest of the image's
manifest, so compute and return that value as the image's reference in
ImageStatus() and in ContainerStatus().
We don't auto-store a name based on the image digest when we pull one by
tag, but then CRI doesn't need us to do that.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Need to mv to latest released and supported version of logrus
switch github.com/Sirupsen/logrus github.com/sirupsen/logrus
Also vendor in latest containers/storage and containers/image
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
The storage library uses github.com/pkg/errors to wrap errors that it
returns from many of its functions, so when passing them to
os.IsNotExist() or comparing them to specific errors defined in the
storage library, unwrap them using errors.Cause().
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Move non-kubernetes-dependent portions of server struct to libkpod.
So far, only the struct fields have been moved and not their dependent
functions
Signed-off-by: Ryan Cole <rcyoalne@gmail.com>
Use containers/storage to store images, pod sandboxes, and containers.
A pod sandbox's infrastructure container has the same ID as the pod to
which it belongs, and all containers also keep track of their pod's ID.
The container configuration that we build using the data in a
CreateContainerRequest is stored in the container's ContainerDirectory
and ContainerRunDirectory.
We catch SIGTERM and SIGINT, and when we receive either, we gracefully
exit the grpc loop. If we also think that there aren't any container
filesystems in use, we attempt to do a clean shutdown of the storage
driver.
The test harness now waits for ocid to exit before attempting to delete
the storage root directory.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Nalin Dahyabhai
Vincent Batts