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>
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 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>
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>
This is an optimization of our image pull code path. It's basically
how docker handles pulls as well. Let's be smart and check the image in
pull code path as well.
This also matches docker behavior which first checks whether we're
allowed to actually pull an image before looking into local storage.
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
The ocid project was renamed to CRI-O, months ago, it is time that we moved
all of the code to the new name. We want to elminate the name ocid from use.
Move fully to crio.
Also cric is being renamed to crioctl for the time being.
Signed-off-by: Dan Walsh <dwalsh@redhat.com>
Remove some logic that messed with the names we assigned to just-pulled
images in the storage layer, since the image and storage libraries now
take care of that for us.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
If an image that we're pulling from a registry has a digest in its
reference, use that to construct the destination image's reference.
This should help us detect cases where the image has previously been
pulled.
When we have a filter to use when listing images, expand it into a
reference so that we can properly match against names of images that
we've previously stored using fully expanded references.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
`image` as a variable/field name becomes too redundant and difficult to
grep for. Switching to `imageServer` makes for more readable code.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
When we pull an image, preserve the tag portion of the name that we were
asked to use for pulling it, instead of unconditionally replacing it
with "latest".
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
When looking for the image to use for creating a container, there's no
need to attempt parsing the ID a second time, and doing so can create
confusing error messages.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
kubelet sends a request to create a container with an image ID (as
opposed as an image name). That ID comes from the ImageStatus response.
This patch fixes that by setting the image ID as well as the image name
and fix the login to lookup for image ID as well.
Found while running `make test-e2e-node`.
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
The CRI doesn't expect us to implicitly pull an image if it isn't
already present before we're asked to use it to create a container, and
the tests no longer depend on us doing so, either.
Limit the logic which attempts to pull an image, if it isn't present, to
only pulling the configured "pause" image, since our use of that image
for running pod sandboxes is an implementation detail that our clients
can't be expected to know or care about. Include the name of the image
that we didn't pull in the error we return when we don't pull one.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Add an intermediate API layer that uses containers/storage, and a
containers/image that has been patched to use it, to manage images and
containers, storing the data that we need to know about containers and
pods in the metadata fields provided by containers/storage.
While ocid manages pods and containers as different types of items, with
disjoint sets of IDs and names, it remains true that every pod includes
at least one container. When a container's only purpose is to serve as
a home for namespaces that are shared with the other containers in the
pod, it is referred to as the pod's infrastructure container.
At the storage level, a pod is stored as its set of containers. We keep
track of both pod IDs and container IDs in the metadata field of
Container objects that the storage library manages for us. Containers
which bear the same pod ID are members of the pod which has that ID.
Other information about the pod, which ocid needs to remember in order
to answer requests for information about the pod, is also kept in the
metadata field of its member containers.
The container's runtime configuration should be stored in the
container's ContainerDirectory, and used as a template. Each time the
container is about to be started, its layer should be mounted, that
configuration template should be read, the template's rootfs location
should be replaced with the mountpoint for the container's layer, and
the result should be saved to the container's ContainerRunDirectory,
for use as the configuration for the container.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
