Do we need a CAS for images on the kubelet?
Opened this issue · 5 comments
The flow I'm thinking of (this is a subset of point 1) and 2) from #6):
- KubeletGenericRuntimeManager->PullImage
- ocid->PullImage
- PullImage->containers/image->GetImage (provides ReaderCloser to containers/storage)
- StoreImage (with containers/storage) to be later used by containers/storage to setup rootfs for containers
- [...]
- Later in the flow in
ocidcontainers/storage will use the previously stored image to setup rootfs and such
Now the hard points are 3) and 4).
Point 3: What do we mean by GetImage? what do we get? Layers blobs + Config? what about the config? should it be saved along with the Manifest or should be later queried when running a container?
Point 4: containers/storage uses the readers from containers/image and save them on disk somehow - and here come a CAS or some image storage (CAS wise, /cc @sgotti)
Point 3: What do we mean by GetImage? what do we get? Layers blobs + Config? what about the config? should it be saved along with the Manifest or should be later queried when running a container?
I think we should get the layers as well as config.
Later in the flow containers/image will use the previously stored image to setup rootfs and such
Can't we do this in ocid instead calling into containers/storage instead of containers/image calling into containers/storage?
Can't we do this in ocid instead calling into containers/storage instead of containers/image calling into containers/storage?
yup sorry if it wasn't clear that ocid will be the wrapper like, first containers/image, then containers/storage in ocid (I fixed the first comment)
I think we should get the layers as well as config.
right basically, like Docker sigh does already - later we probably need something to actually parse the config and provide a Config struct like the one in containers/image#36
So the main stuff still stands, which is how to structure the storage on disk for images