share-nothing pod does not start the infra container

[muayyad-alsadi]

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

/kind bug

Description

when creating a share-nothing pod using podman pod create with --share=""
infra containers is not started and status is reported as Degraded

Steps to reproduce the issue:

$ podman pod create --name=mypod --share=""
93e43419780832f79579ef01f21ac5ba61020bec95db6c3fdf13e2b1b0f5f836
$ podman run -d --name mycontainer1 --pod=mypod busybox httpd -f -p 8123 -h /etc/
243d0b36fb38b8bc55d760ca4756b5ebf29f3a67e561d54042a7ecd99b0f4a09
$ podman pod ls
POD ID        NAME          STATUS      CREATED        INFRA ID      # OF CONTAINERS
93e434197808  mypod         Degraded    2 minutes ago  1e7e9644d101  2
$ podman ps -a -f 'pod=mypod'
CONTAINER ID  IMAGE                                    COMMAND               CREATED        STATUS            PORTS       NAMES
1e7e9644d101  localhost/podman-pause:4.1.0-1653926608                        4 minutes ago  Created                       93e434197808-infra
243d0b36fb38  docker.io/library/busybox:latest         httpd -f -p 8123 ...  3 minutes ago  Up 3 minutes ago              mycontainer1

Describe the results you received:

status is reported as Degraded and infra is created but not started

Describe the results you expected:

status should be up and running and infra should be up

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

Output of podman version:

it applies to both 3.x and 4.x I'm using 4.1.0

podman version 4.1.0

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

podman-4.1.0-8.fc36.x86_64

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)

No

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

this feature is needed by podman-compose when placing multiple containers in a single pod, two containers might have different hostnames

[vrothberg]

Thanks for reaching out, @muayyad-alsadi!

@mheon @cdoern WDYT?

[Luap99]

If there are no shared namespaces we should not create an infra container.
I think by default we only start the infra because other containers depend on it which is not the case without shared namespaces.

[cdoern]

If there are no shared namespaces we should not create an infra container.
I think by default we only start the infra because other containers depend on it which is not the case without shared namespaces.

Yeah I was thinking something similar to this. I'll make a patch today to not create infra in certain scenarios. @mheon does that make sense?

[mheon]

Sure, works for me.

Even if the user manually specifies an infra container but no shared namespaces, the current behavior is still sensible. podman pod start will start the pod. podman run --pod will only start the necessary dependency containers required by container being run - if the infra container is not one of those, it will not be started. Given that, the behavior in question doesn't seem like a bug, but I'm fine with defaulting to no infra container if there are no shared namespaces.

[muayyad-alsadi]

If there are no shared namespaces we should not create an infra container.

in podman-compose I use --infra=false

If there are no shared namespaces we should not create an infra container.
I think by default we only start the infra because other containers depend on it which is not the case without shared namespaces.

Yeah I was thinking something similar to this. I'll make a patch today to not create infra in certain scenarios. @mheon does that make sense?

IMHO this should not be done by podman by default.
I would rather having podman consistent, always create infra and always start it on its own when the pod is started

Given that, the behavior in question doesn't seem like a bug, but I'm fine with defaulting to no infra container if there are no shared namespaces.

IMHO, it's!

podman pod start will start the pod. podman run --pod will only start the necessary dependency containers required by container being run - if the infra container is not one of those, it will not be started.

the behaviour should be consistent with

$ podman pod create --name=mypod2
e25b861bae6c8caea09780e8772ba3e41d6b5cf29e5130d8826a4457249825e9
$ podman run -d --name pod2container1 --pod=mypod2 busybox httpd -f -p 8123 -h /etc/
1caf0d11bf2c4b42d74d5543fafb325c23c0084953739ee920af28aeb6dd8b6f
$ podman pod ls
POD ID        NAME          STATUS      CREATED         INFRA ID      # OF CONTAINERS
e25b861bae6c  mypod2        Running     34 seconds ago  fc18086140a3  2

as you can see here I did not need to start the pod and it's up and running
on the other hand the one in the STRs in the top of the ticket was not running.

same sequence of commands one was Degraded and one was running.
both did not need start.

typically I hate side-effects, I hate to deal with cases because they might break things in many ways

in podman 3.x I remember if there is no infra you can't generate systemd units

You can also see a special infra container. Its primary purpose is to hold specific resources associated with the pod open, such as ports, namespaces, or cgroups. The infra container is the pod's top-level container, and it's created before other containers and destroyed last. You use the infra container when generating systemd units for a pod, so keep in mind that this container runs for the pod's entire lifespan. It also implies that you cannot generate systemd units for pods without an infra container (such as --infra=false).

My suggestion is to have consistent behavior, unconditionally create the infra pod, and always start it.

[cdoern]

it does not make sense to me to keep infra around if it is not doing anything. That is opening up the door for unexpected behavior not to mention a waste of resources and usage/building of the pause image.

[rhatdan]

@vrothberg what happens if I attempted to put one of these pods within a systemd unit file? Doesn't it rely on the creation of the infra container?

Would it make sense to just change the default for --infra=false.

case namespaces == Nil {
infra=false
Default
infra=true

Now if user wants to use an infra with namespaces == nil they need to specify --infra=true.

[muayyad-alsadi]

From my side I explicitly pass infra=false
This is not my issue.

My issue is the inconsistent behaviour of degraded and the need for manually start that is not needed.

Let's assume that the user explicitly asked for a specifically named infra, why it's not started? What is it waiting for? What is the dependency that is pending? Something that has no dependency is something that is auto started not something that never start.

[Luap99]

podman run ... will only start the one create container and all containers that it depends on (namespace sharing or --requires), if the pod has no shared namesapce it is not necessary to start the infra.
A pod will be shown as degraded if not all containers in pod are running. If you want to start everything use podman pod start

[mheon]

Concur with that statement. podman run does not start pods; the fact that it starts dependency containers is largely for convenience and should not be relied on. If you want the entire pod the be running, use podman pod start

[muayyad-alsadi]

Got it.