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

CONTAINER_HOST takes precedence over --connection argument #15588

Closed
jjenne-cisco opened this issue Sep 1, 2022 · 5 comments · Fixed by #19997
Closed

CONTAINER_HOST takes precedence over --connection argument #15588

jjenne-cisco opened this issue Sep 1, 2022 · 5 comments · Fixed by #19997
Assignees
Labels
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

@jjenne-cisco
Copy link

jjenne-cisco commented Sep 1, 2022

/kind bug

Description

When connecting to a remote podman server, CONTAINER_HOST takes precedence over the --connection argument and CONTAINER_CONNECTION variable when selecting the remote in a way that is confusing to the user.

Steps to reproduce the issue:

With two VMs setup with ssh over ports 48011 and 48012:

  1. podman-remote system connection add foo --identity ~/.ssh/id_rsa ssh://root@localhost:48011/run/podman/podman.sock (add foo remote)

  2. podman-remote system connection add bar --identity ~/.ssh/id_rsa ssh://root@localhost:48012/run/podman/podman.sock (add bar remote)

  3. export CONTAINER_HOST=ssh://root@localhost:48011/run/podman/podman.sock (set foo as host)

  4. podman-remote run -it ubuntu bash (launch container on foo)

  5. podman-remote --connection bar ps (check running containers on bar)

Describe the results you received:

When attempting to connect to the bar VM which has no running containers, podman-remote picks up the foo connection from CONTAINER_HOST and shows me:

CONTAINER ID  IMAGE                            COMMAND     CREATED        STATUS            PORTS       NAMES
ff3c2b87d384  docker.io/library/ubuntu:latest  bash        7 seconds ago  Up 7 seconds ago              eloquent_bell

Describe the results you expected:

I expect no containers to be running because I have explicitly passed a connection to the bar remote.

Expect CONTAINER_CONNECTION and the --connection argument to take precedence over the CONTAINER_HOST variable.

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

Even when the default connection is set to be bar, if CONTAINER_HOST points at foo then podman-remote connects to foo. It is not always obvious that an environment variable is set and can be confusing when a CLI arg is used that it does not take precedence.

Output of podman version:

Version:      3.4.4
API Version:  3.4.4
Go Version:   go1.17.3
Built:        Thu Jan  1 00:00:00 1970
OS/Arch:      linux/amd64

Output of podman info:

host:
  arch: amd64
  buildahVersion: 1.23.1
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - hugetlb
  - pids
  - rdma
  - misc
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: 'conmon: /usr/bin/conmon'
    path: /usr/bin/conmon
    version: 'conmon version 2.0.25, commit: unknown'
  cpus: 6
  distribution:
    codename: jammy
    distribution: ubuntu
    version: "22.04"
  eventLogger: journald
  hostname: ubuntu
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.15.0-30-generic
  linkmode: dynamic
  logDriver: journald
  memFree: 3350441984
  memTotal: 6222995456
  ociRuntime:
    name: crun
    package: 'crun: /usr/bin/crun'
    path: /usr/bin/crun
    version: |-
      crun version 0.17
      commit: 0e9229ae34caaebcb86f1fde18de3acaf18c6d9a
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: 'slirp4netns: /usr/bin/slirp4netns'
    version: |-
      slirp4netns version 1.0.1
      commit: 6a7b16babc95b6a3056b33fb45b74a6f62262dd4
      libslirp: 4.6.1
  swapFree: 0
  swapTotal: 0
  uptime: 28m 24.69s
plugins:
  log:
  - k8s-file
  - none
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries: {}
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 1
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /var/lib/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 1
  runRoot: /run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 3.4.4
  Built: 0
  BuiltTime: Thu Jan  1 00:00:00 1970
  GitCommit: ""
  GoVersion: go1.17.3
  OsArch: linux/amd64
  Version: 3.4.4

Package info (e.g. output of rpm -q podman or apt list podman):

podman/jammy,now 3.4.4+ds1-1ubuntu1 amd64 [installed]

Tried on latest podman?

No

@openshift-ci openshift-ci bot added the kind/bug Categorizes issue or PR as related to a bug. label Sep 1, 2022
@jjenne-cisco jjenne-cisco changed the title CONTAINER_HOST takes precedence over CONTAINER_CONNECTION CONTAINER_HOST takes precedence over --connection argument Sep 1, 2022
@cdoern
Copy link
Contributor

cdoern commented Sep 1, 2022

@mheon is this expected behavior? if not I can probably switch it around easily

@mheon
Copy link
Member

mheon commented Sep 1, 2022

Precedence on the environment variables (CONTAINER_HOST vs CONTAINER_CONNECTION) can be debated, but neither should take precedence over the CLI - so I would definitely say not expected.

@LewisGaul
Copy link

LewisGaul commented Sep 1, 2022

The problem is presumably that 'container host/url' and 'container connection' are handled separately, currently with 'host/url' taking precedence over 'connection'. However, they correspond to the same underlying thing (how to connect), so the CLI --connection should probably take precedence over both env vars, and the CLI --url also take precedence over both? Need some way to resolve the case where both are given (across CLI and env vars)...

@github-actions
Copy link

github-actions bot commented Oct 2, 2022

A friendly reminder that this issue had no activity for 30 days.

@rhatdan
Copy link
Member

rhatdan commented Jul 30, 2023

This got lost in the flood of issues, because of the stale-issue flag. Is this still an issue?

@cgiradkar cgiradkar self-assigned this Aug 29, 2023
@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 Dec 20, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 20, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
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.

6 participants