Wildcard docker-image

[testfile2]

What would you like to be added:
The ability to wildcard kind load docker-image. For example kind load docker-image MyProject*:1.0.0 would load MyProjectFrontend:1.0.0 and MyProjectBackend:1.0.0

Why is this needed:
To simplify cluster creation. Every now and again to ensure that clean setup still works I delete the cluster and recreate it. Then have to macro a docker image list in vscode so that I can load all the images into the new cluster with multiple commands. It would be great if we can utilise wildcards to simplify this directly with kind instead of having to write scripts or manually macro the list out.

Linking #1905 since I got there from googling how to do the above

[BenTheElder]

This feature seems a little bit overfit for your particular image naming. I haven't seen many (any?) examples of images with partial naming matches and identical tags that should be simultaneously loaded.

We support essentially the same input as "docker save" and I'm not sure we should be different from that. Tools like skaffold and tilt are also expecting to use this command in kind and other cluster tools and I'm not aware of any other tools having special characters in the input.

[testfile2]

I hear you. However docker save is a purpose built command to save 1 image. I cant think of a case where you would want to use docker save for multiple images. The command is inherently linked to 1 image. Whereas kind, at least in my view, should support loading multiple images at once.

I do see docker images has native support for wildcards when using the --filter option:

$ docker images --filter=reference='busy*:*libc'

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
busybox             uclibc              e02e811dd08f        5 weeks ago         1.09 MB
busybox             glibc               21c16b6787c6        5 weeks ago         4.19 MB

I agree there isn't really a case where a "product" ships multiple images but there is a case when working locally on projects that aren't just 1 "product" and the images are all named by domain. In my previous example you could have MyProject.orders.email and MyProject.orders.tracker etc. This would make dev testing miles easier since if MyProject is quite large you can load all of them in one shot by wildcarding the image name and tag:

kind load docker-image MyProject.orders*:*

instead of

kind load docker-image MyProject.orders.email:1.2.3
kind load docker-image MyProject.orders.tracker:1.4.5
kind load docker-image MyProject.orders.compliants:1.7.3

If you're worried about breaking changes another option is to add the --filter (or whatever you decide) separate from the current load. A new high level command if you will, like kind load docker-image-filter or something to that effect?

[BenTheElder]

I hear you. However docker save is a purpose built command to save 1 image. I cant think of a case where you would want to use docker save for multiple images. The command is inherently linked to 1 image. Whereas kind, at least in my view, should support loading multiple images at once.

That's not the case, it does support multiple in docker. The command is docker save [OPTIONS] IMAGE [IMAGE...] (see the usage, [IMAGE...] is an optional list of additional images).

When you save multiple images together you get a single tarball you can ship around that contains multiple docker images with the shared layers deduped.

kind load docker-image MyProject.orders*:*

It doesn't really make sense to load all tags for an image? This seems like a pretty unlikely development flow.

If you're worried about breaking changes another option is to add the --filter (or whatever you decide) separate from the current load. A new high level command if you will, like kind load docker-image-filter or something to that effect?

We're hoping instead to make future image loading compatible with podman as that node backend matures #2038

If you want to do docker images --filter you can do:
kind load image-archive <(docker images --filter | xargs docker save)

[BenTheElder]

I don't think we want to pursue this versus unifying with podman.