'podman generate kube' confuses 'args' with 'command', and no support for 'command'

[nzjustin]

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

/kind bug

Description

In general (not specific to this issue) there is confusion between the Podman/Docker concepts of:

'entrypoint' and 'command'

And the Kubernetes equivalents of:

'command' and 'args'

Podman/Docker 'entrypoint' = Kubernetes 'command'
Podman/Docker 'command' = Kubernetes 'args'

When you use podman generate kube on a pod/container with custom command arguments they are put as 'command' in the yml file when it should be 'args'. As a side effect of this, there is no support for a custom entrypoint. You either get the default one, or if you also specify a custom argument, you get the argument in place of the command as described previously.

Steps to reproduce the issue:

Create a pod with a container that has a custom (podman/docker) entrypoint and a custom (podman/docker) command:

podman create --entrypoint /bin/sleep --name test --pod new:testpod centos:8 10s

Generate a Kubernetes pod definition:

podman generate kube testpod

Describe the results you received:

The custom command argument is listed as the 'command' (where the entrypoint should be) in the yml output and, as a result the 'entrypoint' is not in the yml file at all.

# Generation of Kubernetes YAML is still under development!
#
# Save the output of this file and use kubectl create -f to import
# it into Kubernetes.
#
# Created with podman-2.0.5
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2021-02-03T00:54:24Z"
  labels:
    app: testpod
  name: testpod
spec:
  containers:
  - command:
    - 10s
    env:
    - name: PATH
      value: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
    - name: TERM
      value: xterm
    - name: container
      value: podman
    - name: HOSTNAME
      value: testpod
    image: docker.io/library/centos:8
    name: test
    resources: {}
    securityContext:
      allowPrivilegeEscalation: true
      capabilities: {}
      privileged: false
      readOnlyRootFilesystem: false
      seLinuxOptions: {}
    workingDir: /
status: {}

Describe the results you expected:

I expected to see

...
containers:
  - command:
    - /bin/sleep
  - args:
    - 10s
...

Output of 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

Apologies I know this is not the latest build. I tried to search the issues and commits but could not find this referenced.

Package info (e.g. output of rpm -q podman or apt list 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?

Checked guide: Yes
Latest version: No

[mheon]

Could you check the behavior again with the Podman 3.0 RCs? We've made numerous changes to play kube since v2.0.5

[vrothberg]

Just tested and I get:

containers:
- command:
  - /bin/sleep
  - 10s

I think that's okay, is it? @haircommander PTAL

[haircommander]

technically that's not correct, but it will work. It's odd that both command and args are string slices, allowing for this behavior.

it would be more correct to have

containers:
- command:
  - /bin/sleep
- args:  
  - 10s

[vrothberg]

Thanks @haircommander. I'll take a look. This looks like a simple fix I can get in before the meetings.