-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatically fork/exec to "podman-remote" if PODMAN_VARLINK_ADDRESS is set / implement podman -H #4390
Comments
I like this proposal, and I think it is something we should do. |
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, |
Ok, Thanks @Romain-Geissler-1A. I will see if someone on our team can take a look. |
@rhatdan I'll knock this out |
Great thanks. BTW Just report an error if podman-remote does not exist on the system. |
@rhatdan Yup or not on PATH |
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. |
Because varlink addresses do not support SSH, we normally recommend using the "bridge" instead. So it should look for the The current workaround is to rename the "podman-remote" program to "podman", on the Mac. See #4511 (comment) for a We argued about the var names, in |
@jwhonce : did you need any help with this ? We do something similar with Now with the new Translating these: https://minikube.sigs.k8s.io/docs/tasks/docker_daemon/
|
@Romain-Geissler-1A : implemented in #4981, using environment variables:
|
Cool thank you ;) |
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 |
No movement on this yet. |
Would it be possible to also install 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/
https://minikube.sigs.k8s.io/docs/handbook/pushing/#3-pushing-directly-to-in-cluster-crio-podman-env
|
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. |
Okay, so I guess we will change it to |
And you will only do this for the HTTP, I guess ? Not for the varlink ? |
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>
.
|
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. |
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:
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.
The text was updated successfully, but these errors were encountered: