Does not it generate a pod anymore? (for podman generate)

[rugk]

Describe the bug
I used to generate the pod/container with podman-compose and then use podman to generate a systemd service out of that.

This does not work anymore, as I get an error that there would be no pod with that name.

To Reproduce

1. With any example do podman-compose -p podname up
2. Now do run podman generate systemd podname --restart-policy=always --new --name --files

Expected behavior
A/Multiple sysemd service file(s) should be generated.

Actual behavior

Error: podname does not refer to a container or pod: no pod with name or ID podname found: no such pod: no container with name or ID "podname" found: no such container

podman pod ps also shows no pods?
So does podman-compose now not create any pods anymore?

I hardly can generate systemd service for each container, I mean I could, but it would be hard to manage those, the pod simplified that a lot, as it could just give me all services I need.

Output

$podman-compose version
['podman', '--version', '']
using podman version: 4.1.0
podman-composer version  1.0.3
podman --version 
podman version 4.1.0
exit code: 0

The ouput of podman-compose up also seems to confirm/does not show any pod being created:

$ podman-compose -p nextcloud up
['podman', '--version', '']
using podman version: 4.1.0
** excluding:  set()
['podman', 'network', 'exists', 'nextcloud_****net']
podman create --name=nextcloud_****_1
ad4a5[…]
exit code: 0
podman volume inspect nextcloud_****_data || podman volume create nextcloud_****_****
['podman', 'volume', 'inspect', 'nextcloud_****_data']
['podman', 'network', 'exists', 'nextcloud_****net']
podman create --name=nextcloud_****_1 […]
e54fa5b6[…]
exit code: 0
podman volume inspect nextcloud_****_**** || podman volume create nextcloud****_****
['podman', 'volume', 'inspect', 'nextcloud_****_****']
['podman', 'network', 'exists', 'nextcloud_****net']
['podman', 'network', 'exists', 'nextcloud_****net']
['podman', 'network', 'exists', 'nextcloud_****net']
podman create --name=nextcloud_****_1 […]
be981413[…]
exit code: 0
podman volume inspect nextcloud****_**** || podman volume create nextcloud_****_****
['podman', 'volume', 'inspect', 'nextcloud_****_****']
['podman', 'network', 'exists', 'nextcloud_****net']
['podman', 'network', 'exists', 'nextcloud_****']
podman create --name=nextcloud_****_1 […]
95b1a2e937bc13c[…]
exit code: 0
podman volume inspect nextcloud_*****_****' || podman volume create nextcloud_*****_****'
['podman', 'volume', 'inspect', 'nextcloud_*****_****']
podman volume inspect nextcloud_***_**** || podman volume create nextcloud_***_****
['podman', 'volume', 'inspect', 'nextcloud_***_****']
podman volume inspect nextcloud_***_****' || podman volume create nextcloud_***_****'
['podman', 'volume', 'inspect', 'nextcloud_***_****']
['podman', 'network', 'exists', 'nextcloud_****net']
podman create --name=nextcloud_**** […]
2e90d1[…]
exit code: 0
podman start -a […]
[…]

Environment:

• OS: Linux / Fedora CoreOS 36.20220522.3.0
• podman version: 4.1.0
• podman compose version: (git hex) 1.0.3

Additional context
The container itself works fine now, only the systemd service generation is a problem, because I seem to have no pod anymore?
Or what am I missing here?

[pdostal]

I reproduced this. Running podman-compose up the containers run but no pod is created.

[rugk]

I also saw #442 (comment), but the suggested --pod-args parameter also does not seem to exist anymore:

$ podman-compose --pod-args='--infra=true --share=""' up
usage: podman-compose [-h] [-v] [-f file] [-p PROJECT_NAME] [--podman-path PODMAN_PATH] [--podman-args args] [--podman-pull-args args] [--podman-push-args args] [--podman-build-args args]
                      [--podman-inspect-args args] [--podman-run-args args] [--podman-start-args args] [--podman-stop-args args] [--podman-rm-args args] [--podman-volume-args args]
                      [--no-ansi] [--no-cleanup] [--dry-run]
                      {help,version,pull,push,build,up,down,ps,run,exec,start,stop,restart,logs} ...
podman-compose: error: argument command: invalid choice: '--pod-args=--infra=true --share=""' (choose from 'help', 'version', 'pull', 'push', 'build', 'up', 'down', 'ps', 'run', 'exec', 'start', 'stop', 'restart', 'logs')

Ah if I read that wrong it is implemented on the dev branch, but not yet released: #379 (comment)

That a pod is re-created.

Well… for systemd service generation that makes a lot of sense still, IMHO.
So I guess I can only refer to this here and ask for a release, given that the issue is actually already fixed.

[muayyad-alsadi]

what is the status of this issue?

[Akruidenberg]

devel version is now creating pods. However localhost is still not working between containers in pods.

[rugk]

The pod can be created with the latest 1.0.6 stable when passing --in-pod=1 to it (in my testing the default was still 0 i.e. to create no pod).
podman generate systemd however does not work with that (it used to work before), because now it says:

Error: generating systemd unit files: Pod "pod_****" has no infra container

I did not had this problem before.

[tomekit]

In my case, if --in-pod 1 I am getting:

Aug 14 06:22:21 nginx1-fsn podman[4568]: Error: no containers in pod 9bbe6d6dd4f4801b5e5db35581a951aa2c2a33ca712120e176a8e60a507081e4 have no dependencies,>

from: systemctl --user enable --now 'podman-compose@compose-nginx1 command

without: --in-pod 1 I am getting:

Aug 14 06:24:11 nginx1-fsn podman[20797]: Error: no pod with name or ID pod_compose-nginx1 found: no such pod

Full command set:

podman-compose --in-pod 1 -f docker-compose.yml -f docker-compose.live.yml up -d 

sudo podman-compose systemd --action create-unit
podman-compose --in-pod 1 -f docker-compose.yml -f docker-compose.live.yml systemd --action register
systemctl --user enable --now 'podman-compose@compose-nginx1'

Since I can't manage to generate proper Systemd for podman-compose at the moment I am generating configs for each container, which is far from ideal, but temporarily solves the issue:

podman generate systemd --new --name container_name1 -f
podman generate systemd --new --name container_name2 -f

Versions

Podman 4.6.1
podman-compose version: 1.0.6

[jaalzateolaya]

@tomekit

podman-compose --in-pod 1 -f docker-compose.yml -f docker-compose.live.yml up -d 

sudo podman-compose systemd --action create-unit
podman-compose --in-pod 1 -f docker-compose.yml -f docker-compose.live.yml systemd --action register
systemctl --user enable --now 'podman-compose@compose-nginx1'

It looks like you have already executed podman-compose up before without --in-pod option, is it the case? Well, since the containers were already created they cannot be attached to the new pod (as far as I understand how it works), so after reading the logs and executing your commands I focussed on running podman-compose up [...] and ensuring the pod gets created with my containers so I solve it by removing the containers and starting from 0:

podman-compose [-f options if needed] down

podman-compose --in-pod 1 up -d

podman ps -a --pod

[...]

PD 1: All the pod thing can be run after sudo podman-compose systemd --action create-unit, so you don't need to "reverse" everything.

[Tiger3018]

Since latest release f6dbce3 (v1.0.6) failed to change the default value when --no-pod was changed to --in-pod, we can change the service file after podman systemd -a create-unit, before commit 7f5ce26 (v1.0.7) is released.

---

The service file is located at /etc/systemd/user/[email protected] .

Insert --in-pod 1. You should also down current compose that is not built with pod.

@@ -6,7 +6,7 @@ Description=%i rootless pod (podman-compose)
 [Service]
 Type=simple
 EnvironmentFile=%h/.config/containers/compose/projects/%i.env
-ExecStartPre=-/usr/bin/podman-compose up --no-start
+ExecStartPre=-/usr/bin/podman-compose --in-pod 1 up --no-start
 ExecStartPre=/usr/bin/podman pod start pod_%i
 ExecStart=/usr/bin/podman-compose wait
 ExecStop=/usr/bin/podman pod stop pod_%i

---

Or simply change the script file at L2042 before create-unit.

[quentino18]

The commit 7f5ce26 (in future v1.0.7) seems to have set the default value to True to fix this issue.

According to this, it seems that it will not be possible to disable pod creation in this way, as in_pod will always be True