unified image loading: podman/docker/nerdctl/tarball

[BenTheElder]

As discussed when podman has come up previously I don't think we should continue making unique image loading commands, instead we should:

• support podman + docker + tarball in a single kind load image
• for each image argument, we should:
  • check for a file first if it looks like a path / check if the file exists
  • check docker
  • check podman

For checking docker vs podman, we can potentially enhance it to cache if docker or podman are even in PATH and skip the ones that aren't installed.

We could also perhaps match the node provider in preferring these, but a couple things to consider:

• what about once we support another provider that may not have the ability to export images?
• what about predictable consistency across hosts?

I think it may be worth sticking to the simplest: a fixed order of these, and ensuring this is fast.
If a script/user really want to load from a particular source, they can always do like podman save hello-world:2 | kind load image -

EDIT: once we agree on the high level approach, I have a few more specific points to add about implementing this correctly.

cc @aojea @amwat @bostrt

[aojea]

For checking docker vs podman, we can potentially enhance it to cache if docker or podman are even in PATH and skip the ones that aren't installed.

We could also perhaps match the node provider in preferring these, but a couple things to consider:

• what about once we support another provider that may not have the ability to export images?
• what about predictable consistency across hosts?

and adding the methods to the provider interface?
If a new provider doesn´t support it, it just throw an error

type Image interface {
   Save(image, dest string) error
   ImageID(image string) (string,error)
}

[BenTheElder]

and adding the methods to the provider interface?

No, because we shouldn't need a provider instance. Even if I use docker to build some image (maybe I'm using a project that uses buildkit / buildx) I should be able to load it into my podman cluster smoothly, and vice versa.

Not to mention file based images that are not even remotely a node provider.

[aojea]

If a script/user really want to load from a particular source, they can always do like podman save hello-world:2 | kind load image -

That is great, and is easy to implement #2041

I like the piping approach and leverage other tools like https://github.com/containers/skopeo to deal with the whole image format thing

[BenTheElder]

We could also perhaps match the node provider in preferring these, but a couple things to consider:

Thinking about this some more, I think it would be reasonable to bump the current node provider to the 2nd preference (after checking for a file matching the argument) for each provider, just moving them and keeping the rest of the list in a fixed order.

Then the results are predictable with future providers, but with each provider we know to have images, we can give preference for the matching image source.

I feel like as a user I would expect podman to have priority when using podman, and docker when using docker.
The order is going to be fairly arbitrary for ignite or any other future provider without this, but should be fixed and predictable / known.

[BenTheElder]

probably also consider OCI images from disk #2626

[corinz]

+1 on this

[BenTheElder]

Note: kind build node-image now supports multiple input sources and seems to be working really well, I think we should take our experience there and develop kind load image with some automatic detection / defaulting of image source and some way for users to override the source.

It can work with (local) tarball files, docker/podman/nerdctl, defaulting to match the provider of the cluster being used, with some option to override the source detection.

I don't think we should support remote tarballs, at least for now, it increases the surface area for little gain, if you're using the network to import an image you should just pull it.

But supporting both tarballs and container images in one command that intelligently selects the source, with fallbacks (users can have multiple runtimes in use ...) and automatically matching the runtime being selected for the nodes makes sense.

I don't think this is terribly complicated, but it needs a little bit of spelling out the design, then implementing.

[BenTheElder]

Also, the reason to sort this out up front is because we're going to run out of good names for these commands, and we get one shot at introducing a new CLI interface before we either burn that name or have to break users (and we strongly prefer to not break users)

[BenTheElder]

cc @aojea @stmcginnis this is a recurring pain point, thoughts?

[stmcginnis]

I really like the idea of having a single kind load image command, regardless of the specific provider.

It can work with (local) tarball files, docker/podman/nerdctl, defaulting to match the provider of the cluster being used, with some option to override the source detection.

+1!