containerd/api/image/image.proto

84 lines
2.8 KiB
Protocol Buffer
Raw Normal View History

syntax = "proto3";
package docker.containerkit.types;
import "github.com/gogo/protobuf/gogoproto/gogo.proto";
import "github.com/docker/containerkit/api/types/mount/mount.proto";
// Images abstracts the graph driver and image store.
//
// The interface is to be able to request and manage images. The output,
// provided as part of the Prepare step, is to expose a set of mounts that can
// be used at container startup to run the image.
service Images {
// Prepare declares that an image is required for use. A prepared image,
// complete with a set of mounts to use for the image will be provided.
rpc Prepare(PrepareRequest) returns (PrepareResponse);
// Cleanup instructs the images service to cleanup resources for the image.
rpc Cleanup(CleanupRequest) returns (CleanupResponse);
// Commit
rpc Commit(CommitRequest) returns (CommitResponse);
// NOTE(stevvooe): Placeholders for other operations here. Consider
// splitting this into a graphdriver like service (Prepare/Cleanup) and an
// image store service.
//
// Really, we want to separate image identification from CAS
// identification, so placing push/pull here may cause too much coupling.
// It might better to be able to import the layers here in the same way the
// graphdriver works, then only use the image metadata to maintain the link
// here.
//
// Basically, we want to avoid the tight coupling present between the image
// store and graphdriver in docker today.
//
// rpc Push(PushRequest) returns (stream PullRequest);
// rpc Pull(PullRequest) returns (stream PullResponse);
}
message PrepareRequest {
// Path specifies the filesystem path to target for the image preparation.
//
// These will influence the values of "target" in the emitted mounts. It
// must be unique per usage of the prepared mount and can only be prepared
// again after a call to cleanup.
string path = 3;
// name of the image to prepare.
string name = 2;
}
message PrepareResponse {
// Layers provides a list of mounts to use with container creation. The
// layers will be mounted, in order, assembling the root filesystem.
//
// Typically, these can be augmented with other mounts from the volume
// service, tmpfs, application-specific bind mounts or even mounts from
// other containers.
repeated types.Mount layers = 1;
// TODO(stevvooe): It is unclear whether or not we should integrate image
// metadata with this part of the service.
}
message CleanupRequest {
// Path cleans up the path used for the image.
// ID identifies the prepared image to cleanup.
string path = 1;
}
message CleanupResponse { }
// CommitRequest provides argument for the Commit RPC.
message CommitRequest {
// Path to a prepared image to capture changes.
string path = 1;
}
message CommitResponse {
// name identifies the entity created as part of the image.
string name = 1;
}