> In this case I recommend creating two containers (independent, not in a pod) and use `podman generate systemd --requires` to control the dependencies.

it was like that, but people asked me to put them in one pod

https://github.com/containers/podman-compose/issues/379

then I liked the ability to use "podman pod stats", "podman pod start", "podman pod logs" ....etc. for the entire stack



On Thu, Feb 24, 2022 at 3:19 PM Valentin Rothberg <vrothberg@redhat.com> wrote:
Hi Muayyad,

Cc @Matt Heon

On Thu, Feb 24, 2022 at 12:05 PM Muayyad AlSadi <alsadi@gmail.com> wrote:
as I said, creating an infra with "--share=" (to be able to set different hostnames) will cause podman pod ps to show status degraded

Can you open an issue for that?
 
> We need one top-level service to manage the pod. 

if the above is solved, I might go with this

this is the part you are talking about

Exactly, that is the part. The `pod-pod_test.service` will be marked as "running" as long as the "5f2458ba5eac-infra" infra container is running.
 
[Unit]
Description=Podman pod-pod_test.service
Documentation=man:podman-generate-systemd(1)
Wants=network-online.target
After=network-online.target
RequiresMountsFor=
Requires=container-test_web80.service container-test_web90.service
Before=container-test_web80.service container-test_web90.service

[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
TimeoutStopSec=70
ExecStart=/usr/bin/podman start 5f2458ba5eac-infra
ExecStop=/usr/bin/podman stop -t 10 5f2458ba5eac-infra
ExecStopPost=/usr/bin/podman stop -t 10 5f2458ba5eac-infra
PIDFile=/run/user/1000/overlay-containers/a3a4ca1b8e4d5a7bcf140be9bff3a3b2c86fa363ecf4b321a6750135dbc2e8c1/userdata/conmon.pid
Type=forking

in case of no infra we can make this part Type=oneshot
or make it the pid of "podman wait" as below

Feel free to change as you see fit but I strongly recommend using `Type=forking` in order to have proper life-cycle management.
 
> We could tie it to the first container in the pod but that may not be a generic solution

I would like to be able to make it the pid of  "podman wait test_web80 test_web90"

In this case I recommend creating two containers (independent, not in a pod) and use `podman generate systemd --requires` to control the dependencies.
 
in my use case, it's a development stack of multiple containers (eg. wordpress, mysql, memcache)
some users want the exit condition to be

1. any container stopped
2. all containers stopped
3. specific container stopped
 
2) could be hard to manage purely in systemd dependencies.

I think that managing all three use cases above should be handled by dependencies in Podman (not by systemd).  All of the 3) conditions could be checked for when a container inside a Pod exists and be acted on accordingly.  It's not possible at the moment but I think it's a nice addition.

Kind regards,
 Valentin

On Thu, Feb 24, 2022 at 11:44 AM Valentin Rothberg <vrothberg@redhat.com> wrote:
Hi Muayyad,

Thanks for reaching out.

On Wed, Feb 23, 2022 at 8:26 PM Muayyad AlSadi <alsadi@gmail.com> wrote:
Hi,

when creating a pod with nothing shared and without infra

podman generate systemd -n pod_test
Error: error generating systemd unit files: Pod "pod_test" has no infra container


here is the full commands

podman pod create --name=pod_test --infra=false --share=
podman network create pod_net
podman run --name=test_web80 -d --net pod_net --hostname web80 --pod=pod_test busybox httpd -f -p 8080 -h /etc
podman run --name=test_web90 --requires=test_web80 -d --net pod_net --hostname web90 --pod=pod_test busybox httpd -f -p 9090 -h /etc
podman pod ps


9a894043a1e1  pod_test        Running     18 seconds ago              2

if we replace 

podman pod create --name=pod_test --infra=false --share=

with

podman pod create --name=pod_test  --share=

podman pod ps

would display Degraded

5f2458ba5eac  pod_test        Degraded    18 seconds ago  a3a4ca1b8e4d  3

if we remove --share=
it would complain about multiple hostnames

what do you suggest?

Using a pod with an infra container will resolve the issue.
 
and why systemd care about infra?

We need one top-level service to manage the pod. The infra container is the main PID of the `pod.service`. As long as the pod is running, the infra is running. Without that, there is no generic way of tracking and managing the life cycle of the pod.

We could tie it to the first container in the pod but that may not be a generic solution: if this container exists, the entire pod would falsely be marked as exited regardless of other containers in the pod which might still be running.

Kind regards,
 Valentin
 
_______________________________________________
Podman mailing list -- podman@lists.podman.io
To unsubscribe send an email to podman-leave@lists.podman.io