If server/Server.createSandboxContainer() fails after calling
server/Server.StorageRuntimeServer().CreateContainer(), cleanup logic in
server/Server.CreateContainer() won't try to clean it up, but we still
need to clean up the on-disk container and its layer.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Have ResolveNames() check if the value that it's been given is a
truncated version of the ID of a locally-available image, and if it is,
return the value as it was given.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Add an UntagImage() method to pkg/storage/ImageServer, which will check
if the passed-in NameOrID is a name. If so, it merely removes that name
from the image, removing the image only if it was the last name that the
image had. If the NameOrID is an image ID, the image is removed, as
RemoveImage() does.
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 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>
github.com/containers/image/types.ImageReference.NewImage() can take a
*github.com/containers/image/types.SystemContext now, so pass it one if
pkg/storage/imageService.CanPull() has one to give it.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Bump containers/image to 3d0304a02154dddc8f97cc833aa0861cea5e9ade, and
containers/storage to 0d32dfce498e06c132c60dac945081bf44c22464.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Some oci runtimes may used stderr for logging. Cri-o should not try to
parse this output as json when calling the "state" command.
Signed-off-by: Nicolas Lacasse <nlacasse@google.com>
Under some slow environment (nested VMs) or with some
not as fast runtimes (Clear Containers), asking for a
status right away is racy.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
