support progress channel for partial pulls

[giuseppe]

currently we do not support progress channel for partial pulls. The entire logic implemented in copy/progress_channel.go is not used when a partial pull is used.

It causes an issue with CRI-O as it uses the notifications from the progress channel to detect whether the pull is still alive, and in case it aborts the operation after 10 seconds.

Since there are some actions that might take more than 10 seconds even when there is no data incoming, e.g. converting to composefs, we should have a mechanism to keep alive the channel (maybe reports dummy events or new kind of notifications?).

[giuseppe]

@mtrmac PTAL, this is an issue with CRI-O since it fails to pull images that take more than 10 seconds

[mtrmac]

Thanks, that’s an interesting interaction. I have commented on that for CRI-O in https://github.com/cri-o/cri-o/pull/8619/files#r1778887578 , perhaps it should be elevated to a separate issue.

Notably, there’s also the “commit” phase of storageImageDestination, which actually extracts the layer tarballs into individual files (or finishes that work if it started concurrently to layer copies), and that can take a very long time, and is not integrated into the progress mechanism.

See also the various “This can take quite some time, and should ideally be cancellable” comments — even in the ordinary layer pull path, where we do generally report progress, we can stop for an arbitrarily-long time in putBlobToPendingFile when extracting a large layer.

So, partial pulls or not, it seems to me that this CRI-O logic is making assumptions on things c/image never promised, and I think short-term CRI-O might need to just give on that.

---

That image pulls “happen very quickly and then hang after the ’Storing signatures’ message” (= in the commit phases) is a long-standing problem. For a long time, that was ~hard to fix without breaking the API of Image{Source,Destination}, and we might have become accustomed to that oddity. Now that we have internal/private, this is all certainly possible to fix.

(Ideally, we’d somehow ~combine copy/progress_bars.go and copy/progress_channels.go into a single progress facility that can be consistently triggered from transports; compare also containers/skopeo#658 and #1532 . But that’s a much larger problem space and we should not block on a perfect solution; I’m just mentioning that to keep that in mind while designing the smaller parts.)

For this specific restricted issue as filed, we we already have blobChunkAccessorProxy, so just to do something similar to what the existing progress channel does, without dealing with the more general issue, we could either extend that proxy, or add one more like it, to send updates to the progress channel.