Commit graph

11 commits

Author SHA1 Message Date
Nalin Dahyabhai
b75a1ba44d Remove some redundant target image namesetting
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>
2017-04-27 14:13:02 -04:00
Nalin Dahyabhai
a0b1da15a3 Expand image refs and handle refs with digests
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>
2017-04-27 14:13:02 -04:00
f401adffa9
server: readable fields
`git grep -w images` or `git grep -w storage` needs to be more useful.

Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
2017-04-20 08:22:50 -04:00
aa24e0554d
pkg/storage: switch to searchable fieldname
`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>
2017-04-18 07:53:53 -04:00
Antonio Murdaca
a0071de607
read image config from docker v2s1 manifests
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
2017-04-04 17:52:37 +02:00
Nalin Dahyabhai
e7748cba6e Preserve the tag of the pulled image's name
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>
2017-03-24 11:54:56 -04:00
Andrew Pilloud
54c176e336 storage: Support latest containers/image
Signed-off-by: Andrew Pilloud <andrewpilloud@igneoussystems.com>
2017-03-13 08:51:02 -07:00
Nalin Dahyabhai
3eca785331 Don't try to parse an image ID a second time
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>
2017-02-08 10:58:00 -05:00
Antonio Murdaca
2202c1a460
storage: fix image retrieval by id
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>
2017-01-31 16:32:30 +01:00
Nalin Dahyabhai
aeea656581 Limit implicit image pulling to the pause image
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>
2017-01-18 10:23:30 -05:00
Nalin Dahyabhai
4ae8606edf Add storage utility functions
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>
2016-12-19 11:44:34 -05:00