Commit graph

11 commits

Author SHA1 Message Date
Nalin Dahyabhai
0b7348b35c Use errors.Cause() when looking at storage errors
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>
2017-08-03 15:40:54 -04:00
Antonio Murdaca
a37dd46654
*: stability fixes
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
2017-06-01 15:42:01 +02:00
Antonio Murdaca
ecd0006e80
vendor: upgrade containers/storage
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
2017-05-17 22:18:07 +02: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
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