cri-o/pkg/storage/doc.go

6 lines
258 B
Go
Raw Normal View History

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-11-22 18:50:33 +00:00
// Package storage provides helper functions for creating and managing CRI pod
// sandboxes and containers and metadata associated with them in the format
// that crio understands. The API it provides should be considered to be
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-11-22 18:50:33 +00:00
// unstable.
package storage