podman play kube (rootless) does not set command and args as specfied at the k8s specs

[cruwe]

/kind bug

Description

https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#notes describes how pods started by k8s are expected to behave when CMD and ENTRYPOINT are (possibly) defined at the image and command and args passed (optionally) from the pod declaration.

When assuming that podman kube play should behave as k8s and podman 2.1 do, this is a bug.

If it should not, which I have difficulties understanding, but, missing deeper insights into the project, cannot rule out, it is a breaking change from 2.1 to 2.2 and should be documented as such.

I have suggested a resolution at #8666, which currently and from my perspective, is stalling. I can only guess for the reasons (hoping not to hurt feelings), but I feel it is not being recognized as either being a bug or being a breaking change.

Personally, I feel that discussing about a fortnight about the resolution of either a bug or a breaking change is too long.
If I have trodden on any feet, I ask to be excused, I do not mean to be disrespectful.

Steps to reproduce the issue:

The problem is that containers from images, which have both ENTRYPOINT and CMD set at the image level, and pod declarations which (legitimately, IMHO) omit command and args, the container does not and cannot start.

Consider the following pod definition:

---
apiVersion: v1
kind: Pod
metadata:
  name: try
spec:
  containers:
    - name: try
      image: docker.io/library/redis:6

Describe the results you received:

With podman 2.2, on the other hand, it crashes, exhibiting

./bin/podman-v2.2 inspect try_pod-try \
| jq '.[] | {"args": .Args, "cmd": .Config.Cmd, "entrypoint": .Config.Entrypoint }'
{
  "args": [
    "docker-entrypoint.sh"
  ],
  "cmd": [
    "docker-entrypoint.sh"
  ],
  "entrypoint": "docker-entrypoint.sh"
}

Describe the results you expected:

With podman 2.1, the pod generating mechanism takes both command and args from the image and starts just fine, which I would expect to continue with 2.2 deriving from my assumption above. If my assumption is false, I'd like to have a loud and clear warning in the changelogs and be grateful for an explanation.

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

#8666 has further details.

[bziemons]

There is #8428 about this. And I do share your frustration about this, but truth is that it happened already and it is more important to talk about how to prevent severe breakages like this in the future. I agree as well this needs to be addressed with a bit more hurry.

[mheon]

Unfortunately most of the team is off for the holidays, so it's unlikely we will have a release out with a fix before the new year. The big takeaway here to me is the need for improved testing on the podman play kube command to catch regressions like this.

[haircommander]

fix and test incoming