extension-api: Add a registration of a loadImage/copyImage provider

[benoitf]

Is your feature request related to a problem? Please describe

For now, some extensions are loading the image from the local registry into a remote registry.
For example kind nodes have their own registries (and then extension use kind load image-archive)

devsandbox extension needs to tag the image using the OpenShift registry URL prefix
minikube configuration with a registry would want to use $(minikube ip):5000/ as well to push the image, etc.

And now each extension contributes its own action 'Push image to ...' and provide their own workflows/notifications/icons

When we deploy a pod yaml to a cluster, we would need to update the YAML with the updated image name as well if they're not already public, ask the user, etc.

Describe the solution you'd like

Add a 'loadImageProvider' option when registering a Kubernetes endpoint connection.

The callback will notify Podman Desktop that the kubernetes endpoint handle the load of an image;

Then, Podman Desktop can register a single or dropdown 'Push to' and Push to Kind, Push to Minikube, Push to DevSandbox, Push to OpenShift Local actions in the images list for each supported running endpoints.

When using the 'Deploy Pod.yaml', user may be asked if he wants to transfer images if they're not public images (Can check if all images are in quay .io do nothing or we can also check the sha of the public image and local image to see if they're the same, etc) and then each extension will be responsible to handle the upload/tag

Podman Desktop will receive the name of the updated image and update accordingly the pod.yaml before submitting it remotely.

Then, experience will be the same for all providers, Kind, OpenShift Local, devSandbox, Minikube, etc and they'll only need to implement a very small subset of only handling the push and returning the name of the image.

Describe alternatives you've considered

No response

Additional context

No response

[afbjorklund]

For example kind nodes have their own registries (and then extension use kind load image-archive)

minikube configuration with a registry would want to use $(minikube ip):5000/ as well to push the image, etc.

minikube uses the minikube image load command, in order to load an existing image to the cluster node(s)

You can deploy a private registry as an alternative, but it might be overkill for users of simple clusters

[afbjorklund]

@benoitf : you might want to consider also a buildImage endpoint, if supported by the provider?

if the build context is small compared to the container image, it might be a quicker turnaround

minikube provides this feature (i.e. both "load" and "build"):

https://minikube.sigs.k8s.io/docs/handbook/pushing/

[benoitf]

It's just to illustrate that minikube extension would be responsible to either call minikube image load or use a local registry or something else ( extension do the specifics, podman desktop the generics)

[benoitf]

Yes it would be possible to consider the build image on k8s clusters as well to have remote build options. We already do that for podman/docker rest API

[benoitf]

From #2866 it would be interesting as well to have a always-on sync running in the background and reporting status of the sync through image list indicators

[deboer-tim]

Or build could have some advanced options for 'when done, push to these registries'.

[benoitf]

@deboer-tim it means using the CLI won't do the trick

[afbjorklund]

The use of the word "registry" is somewhat confusing here. Using one is rather optional, at least for kind/minikube.

It might be recommended, but it is usually also possible to save from the host and load in the cluster? No registry.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 6 months. It will be closed in 30 days if no further activity occurs. Please feel free to leave a comment if you believe the issue is still relevant. Thank you for your contributions!

[github-actions]

This issue has been automatically closed because it has not had any further activity in the last 30 days. Thank you for your contributions!