Is it the only way to enable IPv6 by editing /etc/containers/networks/podman.json for default network?

[839735495]

In order to configure dual stack network for podman default network (backend is netavark), I'd like to define the podman.json configuration file in a separate RPM instead of modify it after creation. However, the 'id' and 'created' fields are things we cannot know in advance.

{
     "name": "podman",
     "id": "???",
     "driver": "bridge",
     "network_interface": "podman0",
     "created": "???",
     "subnets": [
          {
               "subnet": "192.168.229.0/24",
               "gateway": "192.168.229.1"
          },
         {
               "subnet": "fdf8:192:168:229::0/120",
               "gateway": "fdf8:192:168:229::1"
          }
     ],
     "ipv6_enabled": true,
     "internal": false,
     "dns_enabled": false,
     "ipam_options": {
          "driver": "host-local"
     }
}

If I do not provide 'id' and 'created' in the configuration file. Then an error will be reported.

podman network ls
WARN[0000] Network config "/etc/containers/networks/podman.json" could not be parsed, skipping: invalid network ID ""

So, is it the only way to enable IPv6 by editing /etc/containers/networks/podman.json after default network creation?
Also, how to make the changes in podman.json take effect immediately? Can restarting the node be avoided to make changes take effect?
Is there a way to define the configuration file and create a podman default network based on it before creating it?

[Luap99]

If you place the file there it will take immediately effect, however if you modify it you should make sure you have no containers running as it will not change already running container network options. Only containers started after the change pick up the changes.

As for the id and created fields you can just hard code them to any value of your choice, i.e. this will always be the podman id:
https://github.com/containers/common/blob/8cf02b5f7809137b81c349455e1e99c2062e485f/libnetwork/netavark/network.go#L281

[839735495]

Hi @Luap99,
Please check if the summary is correct. Also I have some concerns about it.

To sum up, there are two possible ways to enable IPv6 for default network:

1. We can just deploy the pre-defined /etc/containers/networks/podman.json through RPM installation during node installation.
2. After podman start successfully, just run command "podman network inspect podman | jq.[] >/etc/containers/networks/podman.json" and modify it.

Q for way 1:

1. As you said, for 'id' I can just hard code them to any value of my choice. I assume that you mean any "valid" value which generated by "GenerateNonCryptoID" right? Because it will report error if I set id to "foobar".
2. If I set it to a valid id which generated by "GenerateNonCryptoID", if there by any chances that this id will be occupied by any other upcoming network or container and cause conflict?
3. Does the 'created' field not participated in any calculations or logical judgments? Can we confidently set it to a sufficiently outdated value and ensure that there will be no problems in the future?
4. If I use the reserved ID you mentioned below and the ID is changed in the future, we have to update my code accordingly to adapt the changes. I think it's quite difficult to maintain. CNI backend wouldn't have this problem because we can feel free to provide all necessary info in podman.conflist without providing 'ID' and 'created' fields.
   Also, could you please provided more info about how this ID come and whether it may changed in the future? https://github.com/containers/common/blob/8cf02b5f7809137b81c349455e1e99c2062e485f/libnetwork/netavark/network.go#L281

Q for way 2:

1. In my env, there are several services will be triggered after reboot to run podman container. As you said, if we plan to modify the /etc/containers/networks/podman.json which from "podman network inspect podman | jq.[]", we have to stop all the running containers and modify the config file. Then re-run the services to run containers again. This is a bit troublesome.
2. Maybe we can introduce an additional service to export the default network settings into podman.json and modify it before the containers running? But we need to make sure that this service need to be triggered before all the services which run podman container. Also, if I plan to introduce more services to run other container, we have to take care of the start sequence. This leads to coupling I think.

Thanks!

[Luap99]

Q for way 1:

1. As you said, for 'id' I can just hard code them to any value of my choice. I assume that you mean any "valid" value which generated by "GenerateNonCryptoID" right? Because it will report error if I set id to "foobar".

Yes it should be a valid 64 char hex id but which one should not matter as long as you make sure other network configs in this directoy do not use the same ID.

2. If I set it to a valid id which generated by "GenerateNonCryptoID", if there by any chances that this id will be occupied by any other upcoming network or container and cause conflict?

Networks created by podman network create will never cause a ID conflict as the code checks that the ID is not yet used in any network config. If you create several config files by hand you must make sure they do not conflict by yourself.

3. Does the 'created' field not participated in any calculations or logical judgments? Can we confidently set it to a sufficiently outdated value and ensure that there will be no problems in the future?

The only thing were the date matters is if you filter or sort by date in podman network list or prune and an older value should never cause any issues there.

4. If I use the reserved ID you mentioned below and the ID is changed in the future, we have to update my code accordingly to adapt the changes. I think it's quite difficult to maintain. CNI backend wouldn't have this problem because we can feel free to provide all necessary info in podman.conflist without providing 'ID' and 'created' fields.
   Also, could you please provided more info about how this ID come and whether it may changed in the future? https://github.com/containers/common/blob/8cf02b5f7809137b81c349455e1e99c2062e485f/libnetwork/netavark/network.go#L281

The ID will not change as that would be a breaking change. And even if you have different one it will not matter.

Q for way 2:

1. In my env, there are several services will be triggered after reboot to run podman container. As you said, if we plan to modify the /etc/containers/networks/podman.json which from "podman network inspect podman | jq.[]", we have to stop all the running containers and modify the config file. Then re-run the services to run containers again. This is a bit troublesome.

2. Maybe we can introduce an additional service to export the default network settings into podman.json and modify it before the containers running? But we need to make sure that this service need to be triggered before all the services which run podman container. Also, if I plan to introduce more services to run other container, we have to take care of the start sequence. This leads to coupling I think.

Well if you change a config file you presumably want the changes the apply to your container. So you need to restart them anyway. The main issue is if you change some settings (i.e interface name, ip addresses, etc..) the proper netns cleanup on stop can fail as the code now sees different config compared to the time when the container was started. So yes the only safe way to do it is to stop all containers before changing the config.

[839735495]

Thank you @Luap99, mark it as answered..