containers / containers/podman-compose

Second podman network creation fails with normal name, already prepended in config with podman_files_ it works, but again adds podman_files_.

Open
#1,137 1 comment 0 reactions 0 assignees View on GitHub
bug
Dominant language
Python
Stars
6.2k
Forks
622
PR merge metrics
No merged PRs in 30d

Description

**Describe the bug**
When I define in podman-compose.yml
networks:
backend_net:
driver: bridge
ipam:
config:
- subnet: 192.168.0.0/28
That works well and with podman network ls I see that podman_files_backend_net appeared as expected. However, when I create a second network:
networks:
frontend_net:
driver: bridge
ipam:
config:
- subnet: 192.168.0.16/28
That results in error messages, however when I then define frontend_net as podman_files_frontend_net, that works, but when I look at the output of podman network ls, it has created podman_files_podman_files_frontend_net, so it ends up with twice podman_files in the name.

Secondly, when I predefine the both podman networks it doesn't work at all, for neither of the containers / networks. So, having podman_files_backend_net and podman_files_frontend_net predefined and the the podman_compose.yml file has:
networks:
backend_net: (also tried podman_files_backend_net)
external: true

Then I just get error logs and no network or container started.

**To Reproduce**
Steps to reproduce the behavior:
1. what is the content of the current working directory (ex. `docker-compose.yml`, `.env`, `Dockerfile`, ...etc.)
See description of the bug above.

3. what is the sequence of commands you typed
please use [minimal reproducible example](https://stackoverflow.com/help/minimal-reproducible-example) for example give me a small busybox-based compose yaml
podman-compose -f podman_compose.yml up -d
I also tried:
podman-compose -f podman_compose.yml -p podman_files up -d
Both commands won't create the container nor the network when I defined the second network on 192.168.0.16/28 and the network name set as frontend_net and again, when I set the name as podman_files_frontend_net is does work, but the resulting name is podman_files_podman_files_frontend_net, so twice podman_files.

Having:
networks:
frontend_net:
driver: bridge
ipam:
config:
- subnet: 192.168.0.16/28

# podman-compose -f podman_compose.yml up -d
WARNING:__main__:WARNING: unused networks: frontend_net
Traceback (most recent call last):
File "/usr/local/bin/podman-compose", line 3760, in
main()
File "/usr/local/bin/podman-compose", line 3756, in main
asyncio.run(async_main())
File "/usr/lib/python3.11/asyncio/runners.py", line 190, in run
return runner.run(main)
^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/asyncio/runners.py", line 118, in run
return self._loop.run_until_complete(task)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/asyncio/base_events.py", line 653, in run_until_complete
return future.result()
^^^^^^^^^^^^^^^
File "/usr/local/bin/podman-compose", line 3752, in async_main
await podman_compose.run()
File "/usr/local/bin/podman-compose", line 1866, in run
self._parse_compose_file()
File "/usr/local/bin/podman-compose", line 2063, in _parse_compose_file
raise RuntimeError(f"missing networks: {missing_nets_str}")
RuntimeError: missing networks: podman_files_web_net

**Expected behavior**
Also when I create a second podman network I would expect it to work with a consistent name and when I define frontend_net, this should result in a created podman network name as podman_files_frontend_net. I can get a working situation, but with defining already podman_files_frontend_net, which ends up in a name podman_files_podman_files_frontend_net ( which seems logical, because the name from the podman_compose.yml file will be prepended with podman_files_, however that shouldn't be necessary ).

**Actual behavior**
What is the behavior you actually got and that should not happen.
The podman network only gets created for a second network with a name that already contains podman_files, which then gets prepended with podman_files

Secondly, with an already configured podman network it doesn't work either.

**Output**

```
$ podman-compose version
using podman version: 3.4.1
podman-compose version 1.3.0
podman --version
podman version 3.4.1

$ podman-compose up
...

```

**Environment:**
- OS: Debian 12.9
Output: podman-compose --version
podman-compose version 1.3.0
podman version 4.3.1
podman-compose has been updated today (7 Feb 2025)

- podman version:
- podman compose version: (git hex)

**Additional context**

Add any other context about the problem here.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.