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

Make gvproxy path configurable with containers.conf #11449

Merged
merged 1 commit into from
Sep 14, 2021

Conversation

simnalamburt
Copy link
Contributor

@simnalamburt simnalamburt commented Sep 4, 2021

macOS does not have /usr/libexec/ so we look in the executable paths first.

Closes #11226
Closes #11531

Blocked by containers/common#758

NOTE: This PR is identical with #11234. Since #11226 still exist in the main branch, I'm sending the PR again.

pkg/machine/qemu/machine.go Outdated Show resolved Hide resolved
@jonpspri
Copy link
Contributor

jonpspri commented Sep 5, 2021

I've been reading through the Issue and PR history of this particular PR and two things strike me:

  1. This is partially a Homebrew issue -- the preference of the Podman team is to have gvproxy installed outside off the exec path, and...
  2. The install path prefix in Podman should not be hardcoded but should be a build-time or run-time configuration. That decision could percolate throughout the code base.

Having said that, we may still need the quick fix to fall back to exec.LookPath while the new approach to gvproxy is percolating through homebrew and podman.

@Conan-Kudo
Copy link

macOS does not have /usr/libexec/ so we look in the executable paths first.

It definitely does, though...

@jonpspri
Copy link
Contributor

jonpspri commented Sep 5, 2021

@Conan-Kudo It does, but that directory not user-writable on recent OS releases, and even if it were, installing to System directories flies in the face of Homebrew's philosophy. I think longer-term, podman-machine at least will need to support configurable (install) prefixes and/or some search path capability.

@baude
Copy link
Member

baude commented Sep 5, 2021

@simnalamburt create different search methods by OS (i.e. Linux and Darwin) and we can have a different approach in each. I personally see no issue with the code in 3.3; it just didnt get into main branch yet. Good luck, ill try to check back but im on PTO.

@jonpspri
Copy link
Contributor

jonpspri commented Sep 6, 2021

Perhaps we should consider something like this: jonpspri@562c720

Rather than do backflips in the code, the build process can set the path as a variable. I think in 95% of cases, the target should be known at build time. For example, I updated my Homebrew install to do make GVPROXY_PATH=/opt/homebrew/bin/gvproxy podman-remote-darwin.

Otherwise, I expect we should start looking to an entry in ~/.config/podman. Dunno what the configuration libraries are...

Thoughts?

(p.s. In the next revision, I'll likely use $(shell grep -m1 ^module ./go.mod | cut -f 2 ) to extract the module into a make variable and reduce some unsightly hardcoding in the Makefile.

@jonpspri
Copy link
Contributor

jonpspri commented Sep 6, 2021

I also read up on the Homebrew standards for installs. Homebrew reserves libexec for its own purposes, hence installing gvproxy into ${HOMEBREW_PREFIX}/bin.

@pharaujo
Copy link

pharaujo commented Sep 6, 2021

I also read up on the Homebrew standards for installs. Homebrew reserves libexec for its own purposes, hence installing gvproxy into ${HOMEBREW_PREFIX}/bin.

From my reading of the docs, the libexec directory can definitely be used by formulas, but the binaries placed there just won't be symlinked to HOMEBREW_PREFIX (e.g. /usr/local/libexec). I do think it makes sense to put gvproxy in the formula's libexec directory and have a configurable GVPROXY_PATH set appropriately (e.g. pointing to /usr/local/opt/podman/libexec) at build time.

@jonpspri
Copy link
Contributor

jonpspri commented Sep 7, 2021

@pharaujo I like it. Install into the Keg libexec and use a build-time configuration to direct podman to it. So the make becomes

make GVPROXY_PATH=/opt/homebrew/Cellar/podman/<version>/libexec/gvproxy podman-remote-darwin

I've tested with my formula at https://github.com/jonpspri/homebrew-core/blob/master/Formula/podman.rb while we sort out Pull Requests.

@jonpspri
Copy link
Contributor

jonpspri commented Sep 7, 2021

@ashley-cui ^

jonpspri added a commit to jonpspri/podman that referenced this pull request Sep 9, 2021
Presented as an alternative to PR containers#11449

Rather than do backflips in the code to locate `gvproxy`, use a
build-time variable to set the location.  That variable can default to
`/usr/libexec` but other build packages (_e.g._ Homebrew) can set it to
something of their liking.

I'll take no offense if the consensus is that we do not want to pollute
the build, but we should likely add a runtime configuration parameter as an
alternative in that case.

Fixes: containers#11226

Signed-off-by: Jonathan Springer <[email protected]>
@simnalamburt
Copy link
Contributor Author

We need a consensus.

Current options:

  1. Look up $PATH first and then /usr/libexec/podman/gvproxy38dcd6e
  2. Look up /usr/libexec/podman/gvproxy first and then $PATH → https://github.com/containers/podman/pull/11449/files#r702401547
  3. In Darwin, look up $PATH. Otherwise, use /usr/libexec/podman/gvproxyhttps://github.com/containers/podman/pull/11449/files#r702401547, Make gvproxy path configurable with containers.conf #11449 (comment)
  4. Make it build-time configurable → Use Make GVPROXY_PATH to locate gvproxy #11480
  5. Make it run-time configurable → @Luap99 @vrothberg Use Make GVPROXY_PATH to locate gvproxy #11480 (comment)

Which option do you prefer? I'd prefer option 5.

@jonpspri
Copy link
Contributor

jonpspri commented Sep 9, 2021

@simnalamburt I'm also on board for option 5 (as done over in containers/common#758 ).

@simnalamburt
Copy link
Contributor Author

Oh I didn't notice the progress of over there. Knowing that it is set to option 5, I will find out what I can do to help.

@jonpspri
Copy link
Contributor

jonpspri commented Sep 9, 2021

@simnalamburt One thing you could whip out if you have time is that even once containers/common#758 is merged, we'll still need to refer to the config item in the code this PR addresses. Could you put that together in this PR?

@simnalamburt
Copy link
Contributor Author

simnalamburt commented Sep 9, 2021 via email

@simnalamburt simnalamburt changed the title Fix gvproxy path search for macos Make gvproxy path configurable with containers.conf Sep 10, 2021
@simnalamburt simnalamburt marked this pull request as draft September 10, 2021 20:37
@openshift-ci openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Sep 10, 2021
@simnalamburt
Copy link
Contributor Author

NOTE: This PR is waiting for the new release of https://github.com/containers/common

@Luap99
Copy link
Member

Luap99 commented Sep 13, 2021

@simnalamburt You can vendor in the main branch.
go get github.com/containers/common@main && make vendor

@Luap99
Copy link
Member

Luap99 commented Sep 13, 2021

The new code is merged into podman #11552. If you rebase you should be able to use config.FindHelperBinary()

@baude
Copy link
Member

baude commented Sep 13, 2021

@simnalamburt thanks for your contribution ... can you pleasse rebase this PR and updated with the new method call?

@simnalamburt
Copy link
Contributor Author

Ok I will

@baude
Copy link
Member

baude commented Sep 13, 2021

/approve

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Sep 13, 2021
@baude
Copy link
Member

baude commented Sep 13, 2021

Ok I will

and then of course, we will merge it

@simnalamburt
Copy link
Contributor Author

simnalamburt commented Sep 13, 2021 via email

@simnalamburt simnalamburt force-pushed the gvproxy-path branch 2 times, most recently from 98418aa to 13609ff Compare September 14, 2021 07:51
@simnalamburt simnalamburt marked this pull request as ready for review September 14, 2021 07:51
@openshift-ci openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Sep 14, 2021
@simnalamburt
Copy link
Contributor Author

I've updated and rebased the PR.

BTW, this is the last piece that is needed for podman's Apple Silicon support by default. Yay!

pkg/machine/qemu/machine.go Outdated Show resolved Hide resolved
@Luap99
Copy link
Member

Luap99 commented Sep 14, 2021

@simnalamburt You also have to add [NO TESTS NEEDED] to your commit message.

Closes containers#11531

[NO TESTS NEEDED]

Signed-off-by: Hyeon Kim <[email protected]>
Copy link
Member

@Luap99 Luap99 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@rhatdan
Copy link
Member

rhatdan commented Sep 14, 2021

/approve
/lgtm
/hold

@openshift-ci openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Sep 14, 2021
@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Sep 14, 2021
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Sep 14, 2021

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: baude, Luap99, rhatdan, simnalamburt

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:
  • OWNERS [Luap99,baude,rhatdan]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@baude
Copy link
Member

baude commented Sep 14, 2021

/hold cancel

@openshift-ci openshift-ci bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Sep 14, 2021
@openshift-merge-robot openshift-merge-robot merged commit ad26684 into containers:main Sep 14, 2021
@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 22, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
9 participants