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 generate kube ignores --network=host #9077

Closed
pciavald opened this issue Jan 24, 2021 · 5 comments
Closed

podman generate kube ignores --network=host #9077

pciavald opened this issue Jan 24, 2021 · 5 comments
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

@pciavald
Copy link

pciavald commented Jan 24, 2021

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

/kind bug

Description

When generating the kubernetes manifest for an X11 app that works, the resulting manifest cannot be played for 2 reasons:

  • podman generate adds both CapAdd and privileged keys to the manifest resulting in
Error: invalid config provided: CapAdd and privileged are mutually exclusive options
  • podman play is unable to open X display on the resulting file while the initial pod was able to.
[1:1:0124/140257.102197:ERROR:browser_main_loop.cc(1473)] Unable to open X display.

Steps to reproduce the issue:

  1. create the pod and container, chromium appears, generate the manifest and remove the pod
$ podman pod create --name x11
$ podman run -d \
  --pod x11 \
  --privileged \
  --net host \
  -v /tmp/.X11-unix:/tmp/.X11-unix \
  -e DISPLAY=unix$DISPLAY \
  -v /dev/shm:/dev/shm \
  --name chromium \
  docker.io/jess/chromium
$ podman generate kube x11 >> x11.yml
$ podman pod rm -f x11
  1. play the pod: fails because of mutually exclusive options
$ podman play kube ./x11.yml
Error: invalid config provided: CapAdd and privileged are mutually exclusive options
$ podman pod rm -f x11
  1. comment out capabilities: or privileged: true and run again
$ podman play kube ./x11.yml
$ podman logs x11-chromium
[1:1:0124/142639.642503:ERROR:browser_main_loop.cc(1473)] Unable to open X display.

Describe the results you received:

  • the played pod does not manage to open display
  • the generated manifest is invalid

Describe the results you expected:

  • the played pod should be able to open display like the original pod
  • the generated manifest should be valid

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

Output of podman version:

$ podman version
Version:      2.2.1
API Version:  2.1.0
Go Version:   go1.15.5
Built:        Tue Dec  8 15:37:50 2020
OS/Arch:      linux/amd64

Output of podman info --debug:

$ podman info --debug
host:
  arch: amd64
  buildahVersion: 1.18.0
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.21-3.fc33.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.21, commit: 0f53fb68333bdead5fe4dc5175703e22cf9882ab'
  cpus: 16
  distribution:
    distribution: fedora
    version: "33"
  eventLogger: journald
  hostname: macpro-fedora
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.10.8-200.fc33.x86_64
  linkmode: dynamic
  memFree: 3506880512
  memTotal: 33651884032
  ociRuntime:
    name: crun
    package: crun-0.16-3.fc33.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.16
      commit: eb0145e5ad4d8207e84a327248af76663d4e50dd
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    path: /run/user/1000/podman/podman.sock
  rootless: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.8-1.fc33.x86_64
    version: |-
      slirp4netns version 1.1.8
      commit: d361001f495417b880f20329121e3aa431a8f90f
      libslirp: 4.3.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.0
  swapFree: 3468001280
  swapTotal: 4294963200
  uptime: 95h 52m 39.28s (Approximately 3.96 days)
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - docker.io
store:
  configFile: /home/peac/.config/containers/storage.conf
  containerStore:
    number: 2
    paused: 0
    running: 1
    stopped: 1
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.3.0-1.fc33.x86_64
      Version: |-
        fusermount3 version: 3.9.3
        fuse-overlayfs: version 1.3
        FUSE library version 3.9.3
        using FUSE kernel interface version 7.31
  graphRoot: /home/peac/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 27
  runRoot: /run/user/1000/containers
  volumePath: /home/peac/.local/share/containers/storage/volumes
version:
  APIVersion: 2.1.0
  Built: 1607438270
  BuiltTime: Tue Dec  8 15:37:50 2020
  GitCommit: ""
  GoVersion: go1.15.5
  OsArch: linux/amd64
  Version: 2.2.1

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

podman-2.2.1-1.fc33.x86_64

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?

Yes

Additional environment details (AWS, VirtualBox, physical, etc.):

@openshift-ci-robot openshift-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Jan 24, 2021
@rhatdan rhatdan added the Good First Issue This issue would be a good issue for a first time contributor to undertake. label Jan 25, 2021
@rhatdan
Copy link
Member

rhatdan commented Jan 25, 2021

Looks like it should be pretty easy to fix, Basically don't add cap-add if --privileged is set. Interested in opening a PR?

@pciavald
Copy link
Author

pciavald commented Jan 25, 2021

Yes i can do it. However it still does not work after fixing the conflict in configuration, what do you think about this part ? Maybe I should have created 2 issues for the 2 different problems, in this case the issue is that even when fixing the capabilities, X11 does not open with podman play while it does by creating manually the pod and containers.

@mlegenovic
Copy link
Contributor

@pciavald You have to create pod with --network=host. Generated pod-yaml ignores your --network=host option, and because of that your image is started with default network. That makes the difference between podman play and podman run in your case.

@mlegenovic
Copy link
Contributor

It looks like hostNetwork: true is not exported. This is a bug.

$ podman pod create --name test --network=host
$ podman run -d --pod test --network=host redis:6
$ podman generate kube test | grep hostNetwork | wc -l
0

Tested with podman 2.2.1 and 3.0.0-rc1.
I add hostNetwork: true manually, and try to play kube with podman 2.2.1:

$ podman play kube test.yaml 
Error: namespace value host cannot be provided with namespace mode

podman 3.0.0-rc1 works:

$ podman play kube test.yaml 
Pod:
8ed38732d8ac83436a9ed78111ba3bcdbf35d0cfbea84bbf1a55410b8e83f934
Container:
7f2322bb6e5ea16bea79c91eb5d335151a400a0ad6c2015d31b13f23a029fa6d

@mlegenovic
Copy link
Contributor

mlegenovic commented Jan 27, 2021

This works on my fedora:

$ podman pod create --name x11 --network=host
$ podman run -d --pod x11 --net host -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=unix$DISPLAY --name chromium --user root docker.io/jess/chromium "--no-sandbox"
$ podman generate kube x11 > x11.yaml

Open x11.yaml and add hostNetwork: true

...
spec:
  hostNetwork: true
  containers:
...
$ podman pod stop x11
$ podman pod rm x11
$ podman play kube x11.yaml

@pciavald pciavald changed the title podman play x11 application does not behave the same as podman run podman generate kube ignores --network=host Jan 27, 2021
@pciavald pciavald closed this as completed Feb 2, 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
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

No branches or pull requests

4 participants