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

podman -c ConnectionName doesn't imply --remote #13242

Closed
Romain-Geissler-1A opened this issue Feb 15, 2022 · 2 comments · Fixed by #13296
Closed

podman -c ConnectionName doesn't imply --remote #13242

Romain-Geissler-1A opened this issue Feb 15, 2022 · 2 comments · Fixed by #13296
Labels
Good First Issue This issue would be a good issue for a first time contributor to undertake. kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@Romain-Geissler-1A
Copy link
Contributor

Romain-Geissler-1A commented Feb 15, 2022

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

/kind bug

Description

podman -c ConnectionName doesn't imply flag --remote while I would expect it. It's a bit confusing that if you forgot the --remote flag, then arguments like -c ConnectionName or --url URL are totally ignored. Note that the more or less equivalent "docker context" command (docker -c ContextName) works without any additional flags.

Steps to reproduce the issue:

  1. I have a local setup where "podman.sock" is a regular socker to my local machine (x86_64). And more exotically, I have also a local unix socket named "podman-aarch64.sock" which thanks to the magic of ssh port redirection is actualling targetting a remote podman server on a aarch64 machine. On this remote aarch64 machine, the local podman socket is available at path /run/user/1002/podman/podman.sock.

All these commands are run in a podman in podman scenarios, using quay.io/podman/upstream to check for latest podman version.

[root@102b9b87ef87 /]# ls -la /run/podman/
total 0
drwxr-xr-x 2 root root 80 Feb 15 18:05 .
drwxr-xr-x 1 root root 56 Feb 15 22:32 ..
srw------- 1 root root  0 Feb 15 18:05 podman-aarch64.sock
srw-rw---- 1 root root  0 Feb 15 15:47 podman.sock

[root@102b9b87ef87 /]# podman system connection add aarch64 unix:///run/podman/podman-aarch64.sock

[root@102b9b87ef87 /]# podman system connection list
Name        URI                                     Identity    Default
aarch64     unix:///run/podman/podman-aarch64.sock              true    <--- It's weird to see only one single connection here, marked default,
                                                                       <--- which is actually ignored. Docker "default" context always exists, and by default points to the local docker socket.

[root@102b9b87ef87 /]# podman info|grep sock
    path: /run/podman/podman.sock
[root@102b9b87ef87 /]# podman -c aarch64 info|grep sock
    path: /run/podman/podman.sock  <--- Here I would expect the aarch64 socket (/run/user/1002/podman/podman.sock)
[root@102b9b87ef87 /]# podman --remote -c aarch64 info|grep sock
    path: /run/user/1002/podman/podman.sock <--- This is the good "expected" socket.

Describe the results you received:

I would expect the command podman -c aarch64 info|grep sock to return the aarch64 socket.

Describe the results you expected:

It returns the local x86_64 socket instead.

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

[root@102b9b87ef87 /]# podman version
Client:       Podman Engine
Version:      4.0.0-dev
API Version:  4.0.0-dev
Go Version:   go1.16.14
Git Commit:   5977fd509582d6dc8727ce8f8a78011888a1dc17
Built:        Tue Feb 15 08:06:36 2022
OS/Arch:      linux/amd64```

**Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)**

Yes
@openshift-ci openshift-ci bot added the kind/bug Categorizes issue or PR as related to a bug. label Feb 15, 2022
@rhatdan
Copy link
Member

rhatdan commented Feb 16, 2022

Please open a PR to activate --remote if those options are used. Seems reasonable to me.

@rhatdan rhatdan added the Good First Issue This issue would be a good issue for a first time contributor to undertake. label Feb 16, 2022
@afbjorklund
Copy link
Contributor

afbjorklund commented Feb 16, 2022

There was a similar change to activate remote for CONTAINER_HOST, before environment variables got out of fashion

Romain-Geissler-1A added a commit to Romain-Geissler-1A/podman that referenced this issue Feb 19, 2022
Closes containers#13242

Signed-off-by: Romain Geissler <romain.geissler@amadeus.com>
Romain-Geissler-1A added a commit to Romain-Geissler-1A/podman that referenced this issue Feb 26, 2022
Closes containers#13242

Signed-off-by: Romain Geissler <romain.geissler@amadeus.com>
@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 20, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 20, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Good First Issue This issue would be a good issue for a first time contributor to undertake. kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants