feature request: add a --wait option in skopeo copy

[xwu2intel]

Not sure what's the exact reason, but I find out that docker images copied by skopeo copy are not immediately available to the remote docker daemon or registry, until after some time. This occurs when the images are of moderate or big size, for example, 1GB or bigger. It is as if the remote docker daemon or registry takes some time to re-organize the image content.

Here is the sequence I use:

skopeo copy docker://<local image> docker://<remote image>
while ! skopeo inspect docker://<remote image>; do 
    sleep 1s
done

The request is to add a --wait option in skopeo copy to wait for image availability on the remote docker daemon/registry.

[mtrmac]

Thanks for reaching out.

I interpret this as mostly a registry bug; the registry should delay a success response until the uploaded image/manifest is readable. (In this case, the image seems to just not exist, but in case of copies to a pre-existing tag, the registry would be serving an old image instead). So, legitimizing this behavior by adding special support for it is not immediately attractive to me — especially when there’s a ~reasonably easy workaround, as quoted above, that can be set up without an extra option.

Also, consider a distributed registry backed by multiple servers which can potentially get out of sync, or just take some time to reflect an update..A client-side read can’t tell whether all backends have been updated, only the server aware of the topology and the coordination mechanism can do that.

I’d encourage first trying to find the root cause and try to fix that. Of course there are pragmatic considerations as well — if this behavior were very widespread or fundamentally hard to fix, a client-side workaround might be the right thing to do — but, with the “distributed registry” case, it seems difficult to me to be able to give any sort of guarantee.

BTW

not immediately available to the remote docker daemon or registry

If this means that this is not a registry-specific behavior, but that it happens for multiple destination kinds (copies to docker:// as well as docker-daemon:, for example), that would be very surprising to me, and I’d be curious about a possible common cause.

[xwu2intel]

The remote registry is the standard docker registry:2. This issue occurs mostly on slow machines and to the docker-daemon (docker 26.1.4 on my system) as well. After some wait, the copied images are ready to use.