Automatically fork/exec to "podman-remote" if PODMAN_VARLINK_ADDRESS is set / implement podman -H

[Romain-Geissler-1A]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind feature

Description

Today it seems you have to choose if you run a container locally (by running "podman run") or if you want to run a container remotely (by running "podman-remote run"). It means you don't write the exact same command depending on the mode you want to use. Docker on the other side has a single executable "docker", which queries the environment variable DOCKER_HOST to know to which deamon it shall connect to (and defaults to unix://var/run/docker.sock), whether it's a local deamon or a remote one.

Would it be possible that you:

• Implement an implicit "fork/exec" to "podman-remote" whenever the "podman" executable is invoked, but PODMAN_VARLINK_ADDRESS environment variable is actually set, allowing to transparently use remote container just by a change of an environment variable, and without any change of which executable is launched (ie do not force users to explicitly write "podman-remote" ?
• Implement some -H flag, eg "podman -H run ..." similar to "docker -H run ...", more or less the same way than in point 1 if PODMAN_VARLINK_ADDRESS had been set ?

The use case would typically fixing the classical issues of Docker in Docker (or Podman in Podman) which is either broken or hard to set up correctly without being too limited. This case happens for us in our Jenkins Pipeline flows. The Jenkins slave itself is a Docker container, and as part of the Jenkinsfile it's not uncommon to run other Docker containers inside it. Using Docker in Docker would have many limitations, so today Jenkins relies on Docker side by side Docker, by bind mounting /var/run/docker.sock inside the Jenkins slave container. As one may want the exact same code to run the same way when run through Jenkins (so from a container), and outside Jenkins (so without top level container), it would be cool if "podman" would automatically translate to "podman-remote" just based on some environment variable, just like "docker" does.

[rhatdan]

I like this proposal, and I think it is something we should do.
@Romain-Geissler-1A Interested in opening a PR to make this happen?

[Romain-Geissler-1A]

Hi,

Right now I have never coded anything in Go, and I don't know at all the internal code of podman, so whatever I would produce now will be of very low quality, and would require me quite some time to dig into this project which I don't know yet. So I don't think I am the good candidate for proposing a PR for doing this.

Cheers,
Romain

[rhatdan]

Ok, Thanks @Romain-Geissler-1A. I will see if someone on our team can take a look.
@baude @QiWang19 @jwhonce WDYT?

[jwhonce]

@rhatdan I'll knock this out

[rhatdan]

Great thanks. BTW Just report an error if podman-remote does not exist on the system.

[jwhonce]

@rhatdan Yup or not on PATH

[github-actions]

This issue had no activity for 30 days. In the absence of activity or the "do-not-close" label, the issue will be automatically closed within 7 days.

[afbjorklund]

Because varlink addresses do not support SSH, we normally recommend using the "bridge" instead.

So it should look for the PODMAN_VARLINK_BRIDGE variable as well as PODMAN_VARLINK_ADDRESS

• https://varlink.org/#address

• https://varlink.org/#bridge

The current workaround is to rename the "podman-remote" program to "podman", on the Mac.
It gets really confusing on Linux, though (having two different programs, both named podman)

See #4511 (comment) for a brew example

We argued about the var names, in #4156

[afbjorklund]

@jwhonce : did you need any help with this ? We do something similar with minikube kubectl

Now with the new podman-env support, it does seem a bit odd to keep writing podman-remote...

---

Translating these: https://minikube.sigs.k8s.io/docs/tasks/docker_daemon/

eval $(minikube docker-env)

docker ps

In kubernetes/minikube#6350 (comment)

[afbjorklund]

@Romain-Geissler-1A : implemented in #4981, using environment variables:

• PODMAN_HOST
• PODMAN_VARLINK_BRIDGE
• PODMAN_VARLINK_ADDRESS

[Romain-Geissler-1A]

Cool thank you ;)

[afbjorklund]

I guess this feature never made it into 1.8.0, so we still have to use different commands.

That is, on Mac you use podman but on Linux you use podman-remote - for the same.

[rhatdan]

No movement on this yet.

[afbjorklund]

Would it be possible to also install podman-remote program on Mac and Win, like a symlink ?

That way we could avoid having to have OS-specific tabs (for the path) in the documentation.

https://minikube.sigs.k8s.io/docs/drivers/podman/

minikube start --driver=podman --container-runtime=cri-o

https://minikube.sigs.k8s.io/docs/handbook/pushing/#3-pushing-directly-to-in-cluster-crio-podman-env

eval $(minikube podman-env)

podman-remote ps

podman-remote build -t my_image .

[mheon]

I think the end goal is to have everything be named Podman. Linux builds will have both remote and local support compiled in (removing the need for podman-remote) and Windows/OSX will compile out local support and work like podman-remote does now.

[afbjorklund]

Okay, so I guess we will change it to podman tomorrow then. And watch it fail on Linux.
Unlesss you set up some funky path locally, which is how I am currently testing it...

[afbjorklund]

I think the end goal is to have everything be named Podman.

And you will only do this for the HTTP, I guess ? Not for the varlink ?

[mheon]

Yeah, only HTTP

…

On Sun, May 10, 2020, 13:03 Anders Björklund ***@***.***> wrote: I think the end goal is to have everything be named Podman. I you will only do this for the HTTP, I guess ? Not for the varlink ? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4390 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3AOCFYCZD5SJHA3KN62QLRQ3M43ANCNFSM4JHCLHWQ> .

[rhatdan]

We are moving a way from podman varlink so this is not likely to be fixed, if this issue persists with podman 2.0 (apiv2) then please reopen.