podman play assigns wrong environment vars.

[stxm]

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

/kind bug

Description

podman play assigns environment vars to the wrong containers.

Steps to reproduce the issue:

podman run -dt --rm --name gitea_gitea  --pod new:gitea -p 3000:3000 -p 2222:22 gitea/gitea:latest
podman run -dt --rm --name gitea_postgres --pod gitea postgres:9.6
podman generate kube gitea -f gitea.yml
podman pod rm -f gitea
podman play kube gitea gitea.yml
podman generate kube gitea -f gitea_played.yml
diff -y gitea.yml gitea_played.yml

Describe the results you received:
There is an unexpected difference between the two yaml files
Differences are regarding the env variables.

Describe the results you expected:
I expected both files to be identical or with minor differences

Additional information you deem important (e.g. issue happens only occasionally):
always
Output of podman version:

[root@localhost ~]# podman version
Version:            1.6.4
RemoteAPI Version:  1
Go Version:         go1.12.12
OS/Arch:            linux/amd64

Output of podman info --debug:

debug:
  compiler: gc
  git commit: ""
  go version: go1.12.12
  podman version: 1.6.4
host:
  BuildahVersion: 1.12.0-dev
  CgroupVersion: v1
  Conmon:
    package: conmon-2.0.6-1.module_el8.1.0+272+3e64ee36.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.6, commit: 7a4f0dd7b20a3d4bf9ef3e5cbfac05606b08eac0'
  Distribution:
    distribution: '"centos"'
    version: "8"
  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
  MemFree: 614768640
  MemTotal: 2085666816
  OCIRuntime:
    name: runc
    package: runc-1.0.0-64.rc9.module_el8.1.0+272+3e64ee36.x86_64
    path: /usr/bin/runc
    version: 'runc version spec: 1.0.1-dev'
  SwapFree: 2218782720
  SwapTotal: 2218782720
  arch: amd64
  cpus: 2
  eventlogger: journald
  hostname: localhost.localdomain
  kernel: 4.18.0-147.5.1.el8_1.x86_64
  os: linux
  rootless: true
  slirp4netns:
    Executable: /usr/bin/slirp4netns
    Package: slirp4netns-0.4.2-2.git21fdece.module_el8.1.0+272+3e64ee36.x86_64
    Version: |-
      slirp4netns version 0.4.2+dev
      commit: 21fdece2737dc24ffa3f01a341b8a6854f8b13b4
  uptime: 1h 21m 29.73s (Approximately 0.04 days)
registries:
  blocked: null
  insecure: null
  search:
  - registry.access.redhat.com
  - registry.fedoraproject.org
  - registry.centos.org
  - docker.io
store:
  ConfigFile: /home/sysops/.config/containers/storage.conf
  ContainerStore:
    number: 0
  GraphDriverName: overlay
  GraphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-0.7.2-1.module_el8.1.0+272+3e64ee36.x86_64
      Version: |-
        fuse-overlayfs: version 0.7.2
        FUSE library version 3.2.1
        using FUSE kernel interface version 7.26
  GraphRoot: /home/sysops/.local/share/containers/storage
  GraphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 0
  RunRoot: /run/user/1000
  VolumePath: /home/sysops/.local/share/containers/storage/volumes

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

podman-1.6.4-2.module_el8.1.0+272+3e64ee36.x86_64

Additional environment details (AWS, VirtualBox, physical, etc.):
see attached files
gitea.yml.txt
gitea_played.yml.txt

[rhatdan]

@haircommander Could you take a look at this one?

[github-actions]

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

[rhatdan]

@sujil02 PTAL

[rhatdan]

@sujil02 Did you ever get a chance to look at this, If yes could you hand it over to @ryanchpowell

[sujil02]

@sujil02 Did you ever get a chance to look at this, If yes could you hand it over to @ryanchpowell

Yes, I did look into this a couple of times. But could not get a significant breakthrough @ryanchpowell we can connect and then probably knock this one out together?

[rhatdan]

@haircommander Any chance you could look at this?

[haircommander]

I will try to cleanup these play/generate kube issues

[rhatdan]

You da man.

[haircommander]

it turns out, when we do the initial generate kube we aren't taking the image's env into account, only the containers. Play kube does this, so on the second generate kube, we've picked up the images env. Unfortunately, I believe fixing this requires plumbing all of generate kube with the image.Runtime and ctx to actually be able to inspect the image and get the env out of it. as such, I believe this is more than I am able to take on right now.

[zhangguanzhang]

I don't understand exactly where this problem is. . .

[haircommander]

if the image has environment variables, play kube takes them and adds them to the container's env structure. However, generate kube does not take the image env into account. So first generate does not have image env, first play does have image env, second generate does have image env. does that clear it up @zhangguanzhang

[zhangguanzhang]

if the image has environment variables, play kube takes them and adds them to the container's env structure. However, generate kube does not take the image env into account. So first generate does not have image env, first play does have image env, second generate does have image env. does that clear it up @zhangguanzhang

so need to get all env from ctr first, and remove all the env from the img？

[rhatdan]

Sure, except you need to be careful, they match exactly, IE Name and Value. Otherwise there is a chance the user specified an environment that overroad the default. There is also the corner case where the user created the pod/container with an exact match, but I think we can live with this, as a big corner case.

[rhatdan]

You might want to remove "container=", since Podman adds this itself. And we don't want openshift setting container=podman when a user runs the container on CRI-O.

[github-actions]

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

[rhatdan]

@zhangguanzhang Interested in taking this on?

[zhangguanzhang]

I am busy these days, if the problem is not solved later, I will try

[zhangguanzhang]

I think this problem maybe fixed by #8654, so could you try with the latest version?

[rhatdan]

Reopen if it does not.