missing or incorrect use of --in-pod and pod-args

[az-z]

Describe the bug podman-compose --in-pod=new:my_pod --pod-args="--network=pasta" -f ./podman-compose.yml up ....

podman ps --pod
CONTAINER ID  IMAGE                                               COMMAND               CREATED        STATUS                  PORTS       NAMES                       POD ID        PODNAME
d1eb1653ad28  localhost/podman-pause:4.9.4-1711445992                                   2 minutes ago  Up 2 minutes                        6807f71262f3-infra          6807f71262f3  pod_podman-compose
a0b3bef13e73  docker.io/library/redis:alpine                      redis-server          2 minutes ago  Up 2 minutes (healthy)              podman-compose_redis_1      6807f71262f3  pod_podman-compose
d8c3e7f95720  docker.io/library/rabbitmq:3                        rabbitmq-server       2 minutes ago  Up 2 minutes                        podman-compose_rabbit-mq_1  6807f71262f3  pod_podman-compose

based on the documentation, i expect a new pod with the name "my_pod" to be created. Instead the default " pod_podman-compose" is created.

In addition, the syntaxes for --pod-args are all but clear.

To Reproduce Steps to reproduce the behavior: run the line above. No .env is used.

podman-compose version 1.1.0
podman version 4.9.4

Environment: Fedora release 39 (Thirty Nine)

[apeteri]

--in-pod requires a yes/no answer only, strange that the invocation is not rejected: https://github.com/containers/podman-compose/blob/6d8d3e94fec2df6c3966d07b8371e5c97e014a92/podman_compose.py#L2008-L2013

I've also found supporting evidence in the following comments:

• https://github.com/containers/podman-compose/issues/673#issuecomment-1506756893
• https://github.com/containers/podman-compose/issues/693#issuecomment-1656533771

[az-z]

@apeteri , thank you for looking into the code. This is what I get from the user's perspective:

[az@dell5000 podman-compose]$ podman-compose -v
podman-compose version 1.1.0
podman version 4.9.4

[az@dell5000 podman-compose]$ podman-compose -h
usage: podman-compose [-h] [-v] [--in-pod in_pod] [--pod-args pod_args] [--env-file env_file] [-f file] [--profile profile] [-p PROJECT_NAME] ..........
<skip here>
options:
  -h, --help            show this help message and exit
  -v, --version         show version
  --in-pod in_pod       pod creation
  --pod-args pod_args   custom arguments to be passed to `podman pod`
<skip here>

the way I read it - "--in-pod" should be used for "pod creation". Especially is we look at the "--pod-args" . Looks like (not working ) an attempt to implement pod creation.

no further help seemed to be available for "--in-pod". I may be wrong.

[apeteri]

I've been in your shoes because initially I thought --in-pod expects a pod name without any additional modifiers!

The current reality is that when this value is set to true, a pod will be created whose name matches the project with a "pod_" prefix – this is described in the last comment of #693 linked above and the code is located at: https://github.com/containers/podman-compose/blob/6d8d3e94fec2df6c3966d07b8371e5c97e014a92/podman_compose.py#L348-L359

You'll have to set the project name (either by renaming the directory the Compose file is sitting in or via the --project-name argument) and the name of the pod will be adjusted accordingly.

[az-z]

@apeteri , thank you for digging the source for me! Specifying "yes" and the project name did work. Do you happen to know what is the mystical combination that should be used to specify a particular network mode? Say, I want to create a pod with pasta....

[apeteri]

Compose's network configuration options might be sufficient for this: https://docs.docker.com/compose/networking/#configure-the-default-network

I have two options in mind:

networks:
  default:
    name: pasta

Alternatively if you specify a single network with a key, the default network no longer gets created but its name might be prefixed with the project name and an underscore, as with pods and containers:

networks:
  pasta:

[az-z]

hmmm... That doesn't seem to be working either... If I provide "name: pasta", compose creates a network named "pasta".

I reset the system and specified the default network mode ( is it mode ? or is it a driver? ) to pasta:

[sailtech@dell5000 ~]$  grep cmd ~/.config/containers/containers.conf 
#default_rootless_network_cmd = "slirp4netns"
default_rootless_network_cmd = "pasta"
#network_cmd_path = ""
#network_cmd_options = []

[sailtech@dell5000 ~]$  podman info | grep networkBackend
  networkBackend: netavark
  networkBackendInfo:

[sailtech@dell5000 ~]$ podman run  -d --name=myubi registry.access.redhat.com/ubi8/ubi
[sailtech@dell5000 ~]$ podman inspect --format {{.HostConfig.NetworkMode}} myubi
pasta

[sailtech@dell5000 ~]$ podman-compose --in-pod=yes -f ./podman-compose.yml up
....
[sailtech@dell5000 ~]$ podman inspect --format {{.HostConfig.NetworkMode}} sailtech_restapi_1
bridge

[sailtech@dell5000 ~]$ podman network  ls
NETWORK ID    NAME              DRIVER
2f259bab93aa  podman            bridge
8f1d4e09447a  sailtech_default  bridge

[sailtech@dell5000 ~]$ podman network inspect sailtech_default
[
     {
          "name": "sailtech_default",
          "id": "8f1d4e09447a973e4225ba5262e4405722c480c42dcf70da2934fae2e9c1a91b",
          "driver": "bridge",
          "network_interface": "podman2",
          "created": "2024-06-18T23:07:06.718877522-04:00",
          "subnets": [
               {
                    "subnet": "10.89.1.0/24",
                    "gateway": "10.89.1.1"
               }
          ],
          "ipv6_enabled": false,
          "internal": false,
          "dns_enabled": true,
          "labels": {
               "com.docker.compose.project": "sailtech",
               "io.podman.compose.project": "sailtech"
          },
          "ipam_options": {
               "driver": "host-local"
          }
     }
]

it looks like the compose creates a bridge network ignoring the default setting to pasta ..

[apeteri]

I've misunderstood the assignment 😄 My suggestion indeed should only change the network name, if anything.

Unfortunately I'm not very familiar with Podman's rootless network backends. Perhaps pasta is not mapped to a property in the output of podman network inspect.

[az-z]

I think that (the network part of the problem) will go into a new ticket. (filed #967 ) @apeteri - Thank you for working with me on this quite frustrating issue.

Issue summary:

1. the documentation for --in-pod argument in podman-compose v 4.9.x is insufficient
2. providing unexpected values to --in-pod does not result in errors or warning messages, which breaks the expected functionality ( e.g. containers do not run in the pod as user expects )
3. the documentation for --pod-args is lacking clarity and examples.