runlabel behavior is inconsistent with documentation/atomic

[andrewvaslas]

/kind bug

Description

The runlabel command does not behave in accordance with its documentation. Specifically, the command does not set reserved environment variables (e.g., IMAGE, NAME) in the runlabel context as documentation notes, and the mechanism for specifying custom environment variables (e.g., OPT1, OPT2) is not covered in existing documentation.

Steps to reproduce the issue:

1. Create an image with an INSTALL label defined, following conventions outlined in the example docs.

FROM ...

LABEL INSTALL /usr/bin/podman run -i --rm -v /:/host -e HOST=/host -e NAME=\${NAME} -e IMAGE=\${IMAGE} \${IMAGE}

2. Build the image.

podman build -f Dockerfile -t labeltest:latest

3. Run the labeled command using runlabel.

podman container runlabel install labeltest:latest

Describe the results you received:

$ podman container runlabel install labeltest:latest
Error: requires at least 1 arg(s), only received 0
Error: `/usr/bin/podman run -i --rm -v /:/host -e HOST=/host -e NAME= -e IMAGE=` failed: exit status 125

The error message indicates that that environment variables were not expanded properly, resulting in a failure of the underlying INSTALL command.

Describe the results you expected:

I expected the underlying runlabel command to succeed. Generally, I would expect Podman's documentation to be consistent with its behavior. Specifically, I would expect the implementation of labels to be aligned with the analogous feature that was built into Atomic (as the Podman documentation seems to suggest).

Of note, I looked at the source and was able to see that method by which label strings are converted to fully qualified commands is rather assumptive. Specifically, we seem to rely on specific formatting of env vars for expansion (e.g., $NAME, sans curly braces) or simply the env var key itself (e.g., NAME). Additionally, user-provided options are pulled from the runlabel CLI opts, which isn't really documented anywhere. All that said, I was able to get the label command working with a user-provided option by updating the Dockerfile label to:

LABEL INSTALL /usr/bin/podman run -i --rm -v /:/host -e HOST=/host -e NAME=NAME -e IMAGE=IMAGE -e PORT=\${OPT1} IMAGE

and executing runlabel as follows:

podman container runlabel install labeltest:latest --opt1=5681

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

N/A

Output of podman version:

$ podman version
Version:      2.0.5
API Version:  1
Go Version:   go1.14.7
Built:        Thu Sep 24 17:58:13 2020
OS/Arch:      linux/amd64

Output of podman info --debug:

$ podman info --debug
host:
  arch: amd64
  buildahVersion: 1.15.1
  cgroupVersion: v1
  conmon:
    package: conmon-2.0.20-2.module_el8.3.0+475+c50ce30b.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.20, commit: 1019ecdeda3936be22162bb1cca308192145de53'
  cpus: 8
  distribution:
    distribution: '"centos"'
    version: "8"
  eventLogger: file
  hostname: ip-172-31-19-162.ec2.internal
  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: 4.18.0-240.1.1.el8_3.x86_64
  linkmode: dynamic
  memFree: 9050214400
  memTotal: 33509789696
  ociRuntime:
    name: runc
    package: runc-1.0.0-68.rc92.module_el8.3.0+475+c50ce30b.x86_64
    path: /usr/bin/runc
    version: 'runc version spec: 1.0.2-dev'
  os: linux
  remoteSocket:
    path: /run/user/1000/podman/podman.sock
  rootless: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.4-2.module_el8.3.0+475+c50ce30b.x86_64
    version: |-
      slirp4netns version 1.1.4
      commit: b66ffa8e262507e37fca689822d23430f3357fe8
      libslirp: 4.3.1
      SLIRP_CONFIG_VERSION_MAX: 3
  swapFree: 0
  swapTotal: 0
  uptime: 24h 38m 26.88s (Approximately 1.00 days)
registries:
  search:
  - registry.access.redhat.com
  - registry.redhat.io
  - docker.io
store:
  configFile: /home/centos/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.1.2-3.module_el8.3.0+507+aa0970ae.x86_64
      Version: |-
        fuse-overlayfs: version 1.1.0
        FUSE library version 3.2.1
        using FUSE kernel interface version 7.26
  graphRoot: /home/centos/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 19
  runRoot: /run/user/1000/containers
  volumePath: /home/centos/.local/share/containers/storage/volumes
version:
  APIVersion: 1
  Built: 1600970293
  BuiltTime: Thu Sep 24 17:58:13 2020
  GitCommit: ""
  GoVersion: go1.14.7
  OsArch: linux/amd64
  Version: 2.0.5

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

$ rpm -q podman
podman-2.0.5-5.module_el8.3.0+512+b3b58dca.x86_64

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

No

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

CentOS v8.3 on EC2

[mheon]

@baude PTAL

[andrewvaslas]

@mheon @baude - any updates/thoughts on this?

[github-actions]

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

[computator]

This appears to fix the $NAME and $IMAGE bugs but not update the documentation regarding OPT1, OPT2, etc. Perhaps the issue should be reopened or something.

[rhatdan]

@computator Do you want to open a PR to fix the OPT1, OPT2, OPT3 issue?