fr: serve v1.Images in memory from registry

[howardjohn]

Currently in order to serve images from a registry, we need to push the images there. This may be inefficient in some cases - in particular if we already have a v1.Image in memory for other reasons.

It would be great to be able to preload (or just do an in-memory load) Images to the registry, without the cost of a push.

A concrete usecase would be to build and image, serve it as a registry and trigger kind to pull from it; this is much more efficient than ctr load.

[imjasonh]

We've had some plans to make cmd/registry more pluggable, so that it can serve images from OCI layouts on disk, in addition to serving images from memory like it does today. I don't think we've really explored any other cmd/registry-specific options for "pushing" directly into its storage in memory, skipping the push process. Once we make some more progress on making cmd/registry more pluggable that might be an option worth exploring.

[howardjohn]

I played around with this a bit. I found internally 'pushing' through the blobHandlers wasn't any faster than just pushing to an external registry (running on the same network - not gcr.io or something like that where we are network bound) - a lot of time spent on copying blobs and verifying the hashes on the reads. So I ended up doing a bit more surgery to get a more direct path from the v1.Image to the incoming requests.

Pushed a branch up howardjohn/istio@41a7e3a. Major caveat - this is super quickly hacked together and horrible quality, likely handles on the specific cases I was trying, etc.

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Keep fresh with the 'lifecycle/frozen' label.