While it initially seemed easy, skipping the pull image phase in cri-o proved problematic.

When I tried to do it, kubernetes seemed happy to be told that the pull was done even if it didn't, even after subsequent "ImageStatus" or "ImageList" request proved that it was not there. But cri-o itself, during the "CreateContainer" phase, started to have issues.

cri-o needs to access the image metadata to properly report status on the container it creates, or to get the entrypoint, and so on. Since we're not pulling the image, it can't find that, and fails.

I've tried to skip those too, putting defaults or fake values, knowing that the kata VM would download and use the actual image in the end, but this still doesn't work - each change leads to another failure down the road, and it makes a pretty messy code.

Alternatively I've tried to make cri-o use a "sane default image" (the pause image), that we know is always available in the repository. But this is causing another kind of issue: cri-o then looks the entrypoint from it, and tells the kata agent to use that. It also reports wrong information to kubelet, which then pretends that the container is just running the pause image.

All in all, it seems that cri-o needs to pull the actual metadata of the image, so that it can have consistent information to report both up (to kubelet) and down (to the kata agent), while not pulling the image's layers, which may be encrypted and cause the issue we're trying to fix. But I'm not sure how to make that happen cleanly as the pull phase of cri-o is implemented within libraries (vendored code). I need to find the right place to modify, with as little side effect as possible. 

This spike will track that investigation.