Open rwmjones opened 9 months ago
@mtrmac PTAL
The commands which lead to this are:
$ podman pull docker://kubevirt/fedora-cloud-container-disk-demo
Trying to pull docker.io/kubevirt/fedora-cloud-container-disk-demo:latest...
Getting image source signatures
Copying blob 7e9e1841b94b skipped: already exists
Copying config ce9e1ebe44 done |
Writing manifest to image destination
ce9e1ebe442a8c85fc9c6664c4d9de61aac7a51d76bca65935d514e836683020
$ podman save --format oci-dir -o /tmp/dir2 docker://kubevirt/fedora-cloud-container-disk-demo
Error: unsupported transport "docker" for looking up local images
I still haven't found a way to fix it.
@rwmjones So are you saying that pull
worked once, then save
failed, and later pull
is broken?
Or is the report only that save
rejects the docker://
syntax?
If it is the latter, that’s expected behavior — save
means “export an image in local storage”, and docker://…
is not a way to refer to an image in local storage.
… and the way to run save
correctly should be to just drop the docker://
prefix, turning the argument into a reference to the already-pulled image.
(BTW, if the only purpose of these commands were to create the OCI directory, I’d expect skopeo copy docker://… oci:…
to be significantly faster).
So this used to work at some point in the past and is now giving this error.
How do I know that I can just drop the docker://
prefix to refer to an image in local storage?
Never heard of skopeo
before.
For example these commands work fine, having the same "pattern" of "pull the thing then save the thing" without needing to change the container URI:
$ podman pull quay.io/kubevirt/fedora-cloud-container-disk-demo
$ podman save --format oci-dir -o /tmp/dir2 quay.io/kubevirt/fedora-cloud-container-disk-demo
The docker://
syntax specifically refers to an image on the registry. Using podman save docker://…
is just a category error.
This situation is the containers equivalent of
wget https://example.com/document
cat https://example.com/document # why doesn’t this work??!
If that was previously accepted, I’m afraid that’s just a bug (https://docs.podman.io/en/latest/markdown/podman-pull.1.html documents that it accepts the transport:
details syntax, https://docs.podman.io/en/latest/markdown/podman-save.1.html does not). I’m open to an argument that no longer accepting podman save docker://…
is a compatibility breakage and that we need to keep that working; I don’t have an immediate opinion on that.
I could also see an argument that this should be accepted purely for symmetry and user convenience; I’m far less sympathetic to that view, because there’s an inherent ambiguity / semantics conflict. If the contents of the registry tag change, should podman save docker://…
refer to the image as it exists in local storage (even if obsolete), or to the latest version as it exists on the registry? docker://
means on the registry, after all.
podman pull quay.io/…; podman save quay.io/…
work because those inputs are intentionally designed as an user convenience, and heuristically parsed (in quite a few, some possibly surprising ways) [and because those inputs must be compatible with docker
(1)]. The ultimate case of this heuristic/convenience aspect is that podman run example.com/foo
will either refer to an image in local storage, or automatically pull it; the input carries both semantics depending on the current situation.
docker://
is the conceptual opposite to that: the transport:
details syntax is intended to be non-ambiguous and explicit — but that also means that users that choose an explicit syntax have to say precisely what they mean, and not expect that the computer will figure it out.
But the error message says nothing about how to fix this. It implies that podman save docker://
could work if only docker:
was a supported transport, perhaps by installing an extra package. That's the root cause problem here, the error message is meaningless and non-actionable.
Another way to put it: 95% of your users are not experts on when to use a URI and when to use a local image reference. They'll look up the error on their favourite search engine and find nothing useful about how to solve this (as I found too).
You got this error, what error:
$ podman save --format oci-dir -o /tmp/dir2 docker://kubevirt/fedora-cloud-container-disk-demo
Error: unsupported transport "docker" for looking up local images
What error message would have helped?
It could say something like:
Error: podman save: "docker://kubevirt/fedora-cloud-container-disk-demo" is
not the name of a downloaded image. If you want to save from a URI, use
podman pull first, and then use the name of the local image[*]
[*] or whatever is the appropriate term for a pulled/downloaded image, as that's not clear to me
BTW I checked the man page for podman-save
and it starts with "podman save saves an image to a local file or directory". This doesn't imply to me that the "image" must be a local, already downloaded image. In fact it doesn't say anywhere in the man page that you to have already pulled/downloaded the image. Literally the words "pull" or "download" don't occur on the page, and "local" is only used to refer to the "local file".
Issue Description
Using a podman command with a
docker://
URI I get this error:This error doesn't tell me what to do to fix the problem, ie. it is a non-actionable error message.
Steps to reproduce the issue
Steps to reproduce the issue
docker://
URIpodman info output
Podman in a container
No
Privileged Or Rootless
None
Upstream Latest Release
No
Additional environment details
Fedora Rawhide
Additional information
No response