Any plan to upgrade podman?

Feature requests
1

podman version in vyos 1.5 is 4.9.5 , it was released 2 years ago. latest podman is already 6.0.

2
2 Likes
3

What are the major feature differences between version 4.9.5 and 5.8.4?

4
5

not sure if it is time to switch podman firewall driver to nftables . I guess iptables is only used for containers now . thanks !

6

Yeah but that only shows for 5.8 alone.

Im guessing there are more minor versions between 4.9.5 and 5.8.4?

I mean I can read at Releases · podman-container-tools/podman · GitHub but what are the summary of why this should be upgraded to begin with?

Any CVE’s resolved?

Any good new features or just added junk to the codebase?

And if new features added - does the templates for vyos-configd be updated aswell?

7

CVEs fixed according to podman release notes.

This is a version bump first before any new features can be added/enabled.

2 Likes
8

One useful new feature is this:

- The `--network` option to `podman run`, `podman create`, and `podman pod create` now
accepts a new option for `bridge` networks, `host_interface_name`, which specifies a name
for the network interface created outside the container.

There’s currently 2 issues:

  1. User created and podman created veth interfaces are ambiguous. If a user has 4 containers in a bridge network, and then tries to configure a veth pair using veth1 and veth2, it will throw an exception and the user won’t know why their config isn’t working. There’s currently a task for this: ⚓ T7736 Container: virtual-ethernet exception when attempting to modify container network created veth
  2. Podman created veth interfaces are not deterministic. If a user creates container1, and then later creates container2, they would expect to get container1=veth1 and container2=veth2. But if container2 is actually alphabetically superior to container1, upon a reboot, that would get swapped, with container1 now owning veth2, and container2 owning veth1. If they had made firewall rules, or any other config expecting a specific interface name for that container in the podman bridge network, then it would no longer be valid.

The new feature would allow the veth interfaces to be named something like veth-<container name> rather than just veth<n>. This prevents both of those issues.

9

Sounds like networks would then finally get proper VRF support? :slight_smile:

I know there is currently a VRF setting in VyOS when defining container networks but that doesnt seem to currently work as I expect it to work (at least not in Stream 2026.03).

10

I found it set the container network bridge 's master to vrf device , it should be as expected ,rt ?