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>
We need to support cases where InitCNI() is called before
any CNI configuration files have been installed. This is
for example happening when deploying a k8s cluster with kubeadm.
kubeadm will start the DNS pod and it is left to the caller to
pick a network overlay and create the corresponding pods, that
will typically install a CNI configuration file first.
Here we address that issue by doing 2 things:
- Not returning an error when the default CNI config files
directory is empty.
- If it is empty, we start a monitoring thread (fsnotify based)
that will synchronize the network configuration when a CNI
file is installed there.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
To be consistent with the rest of the CRI-O logs, and to be able
to set the ocicni verbosity, we convert it from glog to logrus.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.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>
