Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

load: kind load docker-image .. is non-functional for provider podman #2729

Closed
flouthoc opened this issue Apr 26, 2022 · 2 comments
Closed
Labels
kind/bug Categorizes issue or PR as related to a bug.

Comments

@flouthoc
Copy link
Contributor

As of now kind hardcodes looking and loading images from docker
as a result kind load docker-image : does not works well when
Provider is configured as podman instead of docker.

Following PR makes sure that kind supports loading images irrespective of
the providers configured and works for both podman and docker

What happened:
kind load docker-image <image-name>:<image-tag> is not functional when provider is configured as podman.

What you expected to happen:
To get image uploaded into control-plane

How to reproduce it (as minimally and precisely as possible):

[root@fedora ~]# kind load docker-image localhost/test:latest
enabling experimental podman provider
ERROR: image: "localhost/test:latest" not present locally

Anything else we need to know?:
I think this can be fixed by: #2728

@flouthoc flouthoc added the kind/bug Categorizes issue or PR as related to a bug. label Apr 26, 2022
@BenTheElder
Copy link
Member

it is expected that kind load docker-image only supports ... docker, docker is in the name

#2038 for the tracking issue re: we should have a multi-provider option.

in the meantime: podman save image | kind load image-archive -

@flouthoc
Copy link
Contributor Author

@BenTheElder Thanks for promptly replying. Ah i see if there is already a plan for unification of image command then that would be better. Podman still supports docker-image format but command is a no-op when docker is not present on the host hence I thought it would be better to use whatever provider is present.

I can use my patch or a workaround till this is fixed upstream. This issue is not a blocker for my use-case so its perfectly fine to wait for unification of image command.

Please feel free to close this issue if this is already being tracked somewhere to avoid redundancy.

Cheers 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants