Skip to content
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

Closed
Romain-Geissler-1A opened this issue Oct 31, 2019 · 19 comments
Assignees
Labels
do-not-close kind/feature Categorizes issue or PR as related to a new feature. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. stale-issue

Comments

@Romain-Geissler-1A
Copy link
Contributor

Romain-Geissler-1A commented Oct 31, 2019

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.

@openshift-ci-robot openshift-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Oct 31, 2019
@Romain-Geissler-1A Romain-Geissler-1A changed the title Automatically fork/exec to "podman-remote" PODMAN_VARLINK_ADDRESS is set / implement podman -H Automatically fork/exec to "podman-remote" if PODMAN_VARLINK_ADDRESS is set / implement podman -H Oct 31, 2019
@rhatdan
Copy link
Member

rhatdan commented Nov 7, 2019

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
Copy link
Contributor Author

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
Copy link
Member

rhatdan commented Nov 7, 2019

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

@jwhonce
Copy link
Member

jwhonce commented Nov 7, 2019

@rhatdan I'll knock this out

@rhatdan
Copy link
Member

rhatdan commented Nov 7, 2019

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

@jwhonce
Copy link
Member

jwhonce commented Nov 7, 2019

@rhatdan Yup or not on PATH

@github-actions
Copy link

github-actions bot commented Dec 8, 2019

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
Copy link
Contributor

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

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
Copy link
Contributor

@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
Copy link
Contributor

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

  • PODMAN_HOST
  • PODMAN_VARLINK_BRIDGE
  • PODMAN_VARLINK_ADDRESS

@Romain-Geissler-1A
Copy link
Contributor Author

Cool thank you ;)

@afbjorklund
Copy link
Contributor

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
Copy link
Member

rhatdan commented Feb 18, 2020

No movement on this yet.

@afbjorklund
Copy link
Contributor

afbjorklund commented May 10, 2020

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
Copy link
Member

mheon commented May 10, 2020

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
Copy link
Contributor

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
Copy link
Contributor

afbjorklund commented May 10, 2020

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
Copy link
Member

mheon commented May 10, 2020 via email

@rhatdan
Copy link
Member

rhatdan commented Jun 9, 2020

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.

@rhatdan rhatdan closed this as completed Jun 9, 2020
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 23, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
do-not-close kind/feature Categorizes issue or PR as related to a new feature. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. stale-issue
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants