kubernetes-testing-framework icon indicating copy to clipboard operation
kubernetes-testing-framework copied to clipboard

Loading image into cluster fails if the image is not available locally: consider falling back to pulling the image

Open pmalek opened this issue 2 years ago • 2 comments

Is there an existing issue for this?

  • [X] I have searched the existing issues

Problem Statement

Currently when the requested image is not available locally, kind (the only implementation that we support) will return an error:

ERROR: image: "<IMAGE>" not present locally

which might be a problem in e.g. complicated CI systems where multiple images are to be used as overrides in CI workflows and a single flag is used for that purpose in order to load the images into a cluster, where 1 image might be locally built and requires loading whereas others are available in external container image registries and do not require loading.

This creates a problem for maintainers of such workflows.

Proposed Solution

  • Implement a fallback mechanism where, whenever an error indicating that an image that was requested in not available locally, we fall back to trying to pull it from an external registry this way being more resilient to errors which should not be considered fatal.

Additional information

No response

Acceptance Criteria

  • [ ] As a user I can rely on KTF to fall back to pulling an image from an external registry if it's not available locally and only then report a failure about a missing image.

pmalek avatar May 15 '23 16:05 pmalek

Sounds like we want to go from having a "load this image into the cluster from the local systems" utility, to a utility that does "pull this image into the cluster from a remote registry, optimizing from the local system cache when possible" utility. It sounds fine to add this, we should just make sure we're explicit and perhaps additive (e.g. have a separate function rather than replacing the current one, if there are places where we're using this today where the fallback position would not be wanted)?

shaneutt avatar May 15 '23 17:05 shaneutt

Sounds like we want to go from having a "load this image into the cluster from the local systems" utility, to a utility that does "pull this image into the cluster from a remote registry, optimizing from the local system cache when possible" utility.

Personally I was thinking about the same but in reverse: so the goal would be "load the image from local daemon, if unavailable then fall back to pulling from a registry (as specified by the image name)"

pmalek avatar May 15 '23 17:05 pmalek