This tracks Podman v5.3.0 test week which will be happening 2024-10-28.
@lsm5 suggest the following. a) are the dates working for y'all? b) can you suggest any test case we should be adding? c) anything else to keep in mind? like known issues?
@mohanboddu @mheon @dwalsh @baude PTAL
also, now that F41 is out, I suppose it will be tested on Fedora Rawhide? or do you folks want to test on F41 ?
Can we ask for testing on either / both ? I don't have a strong preference but I think it'll be good to have whatever data we can get.
Also:
a) are the dates working for y'all?
Does that become too early if we're targeting Nov 12 release? It's alright with me as such, and I'm also cool if we want to extend it by another week.
b) can you suggest any test case we should be adding?
We can probably copy over the cases from last time. Also, for 5.3, I think pasta related tests might be useful. @luap99 PTAL as well.
c) anything else to keep in mind? like known issues?
Hopefully not. Though others cc'd might have something.
Also copying @rishi @martinpitt @dustymabe for toolbox, cockpit and coreos respectively.
The plan is to cut rc2 on the 29th, I don't expect anything big/important in there that wasn't in rc1 so it is not a big deal but maybe it is better to wait for rc2 builds to test?
As for pasta I plan to publish a blog later that highlights two changes, I don't think there is any particular risk with the changes but if people want to test: New host.containers.internal logic that uses pasta's --map-guest-addr option
$ podman run -d -p 8080:80 docker.io/library/nginx 838c2deff63a63c856e7a8e64c7c5b0d69419b8c663275b4e5866ec73ad5ae92 $ podman run --rm -it docker.io/library/nginx:latest curl host.containers.internal:8080 <!DOCTYPE html> ... $ podman rm -fa -t0 838c2deff63a63c856e7a8e64c7c5b0d69419b8c663275b4e5866ec73ad5ae92 $ podman run -d -p 127.0.0.1:8080:80 docker.io/library/nginx 2986c84d3a27027d32670882b33be5f6e0a4d09f1587c4df0440224d25149177 $ podman run --rm -it docker.io/library/nginx:latest curl host.containers.internal:8080 <-- this should hang, access to socket bound on 127.0.0.1 should not be allowed via host.containers.internal -->
Second, rootless quadlet startup due pasta failing (https://github.com/containers/podman/issues/22197). Define a simple quadlet file that starts on boot, also ensure you have lingering enabled for the user.
$ cat ~/.config/containers/systemd/t1.container [Container] Image=quay.io/libpod/testimage:20240123 Exec=ip addr [Install] WantedBy=default.target
As long as the container uses the default network or any bridge network it should always correctly start now as before it was racy depending on how long network setup took on the host. See the issue for more details. Then reboot
also, now that F41 is out, I suppose it will be tested on Fedora Rawhide? or do you folks want to test on F41 ? Can we ask for testing on either / both ? I don't have a strong preference but I think it'll be good to have whatever data we can get.
Sure, Lets do both in that case will be have Bodhi update links for builds where people will be able to submit karma.
Also: a) are the dates working for y'all? Does that become too early if we're targeting Nov 12 release? It's alright with me as such, and I'm also cool if we want to extend it by another week. b) can you suggest any test case we should be adding? We can probably copy over the cases from last time. Also, for 5.3, I think pasta related tests might be useful. @luap99 PTAL as well.
I am reading about pasta now :)
c) anything else to keep in mind? like known issues? Hopefully not. Though others cc'd might have something. Also copying @rishi @martinpitt @dustymabe for toolbox, cockpit and coreos respectively.
So push it by a few days maybe 1st Nov through 8th Nov?
As for pasta I plan to publish a blog later that highlights two changes, I don't think there is any particular risk with the changes but if people want to test: New host.containers.internal logic that uses pasta's --map-guest-addr option ``` $ podman run -d -p 8080:80 docker.io/library/nginx 838c2deff63a63c856e7a8e64c7c5b0d69419b8c663275b4e5866ec73ad5ae92 $ podman run --rm -it docker.io/library/nginx:latest curl host.containers.internal:8080 <!DOCTYPE html> ... $ podman rm -fa -t0 838c2deff63a63c856e7a8e64c7c5b0d69419b8c663275b4e5866ec73ad5ae92 $ podman run -d -p 127.0.0.1:8080:80 docker.io/library/nginx 2986c84d3a27027d32670882b33be5f6e0a4d09f1587c4df0440224d25149177 $ podman run --rm -it docker.io/library/nginx:latest curl host.containers.internal:8080 <-- this should hang, access to socket bound on 127.0.0.1 should not be allowed via host.containers.internal --> ``` Second, rootless quadlet startup due pasta failing (https://github.com/containers/podman/issues/22197). Define a simple quadlet file that starts on boot, also ensure you have lingering enabled for the user. ``` $ cat ~/.config/containers/systemd/t1.container [Container] Image=quay.io/libpod/testimage:20240123 Exec=ip addr [Install] WantedBy=default.target ``` As long as the container uses the default network or any bridge network it should always correctly start now as before it was racy depending on how long network setup took on the host. See the issue for more details. Then reboot
As for pasta I plan to publish a blog later that highlights two changes, I don't think there is any particular risk with the changes but if people want to test: New host.containers.internal logic that uses pasta's --map-guest-addr option ``` $ podman run -d -p 8080:80 docker.io/library/nginx 838c2deff63a63c856e7a8e64c7c5b0d69419b8c663275b4e5866ec73ad5ae92 $ podman run --rm -it docker.io/library/nginx:latest curl host.containers.internal:8080 <!DOCTYPE html> ... $ podman rm -fa -t0 838c2deff63a63c856e7a8e64c7c5b0d69419b8c663275b4e5866ec73ad5ae92 $ podman run -d -p 127.0.0.1:8080:80 docker.io/library/nginx 2986c84d3a27027d32670882b33be5f6e0a4d09f1587c4df0440224d25149177 $ podman run --rm -it docker.io/library/nginx:latest curl host.containers.internal:8080 <-- this should hang, access to socket bound on 127.0.0.1 should not be allowed via host.containers.internal -->
```
Second, rootless quadlet startup due pasta failing (https://github.com/containers/podman/issues/22197). Define a simple quadlet file that starts on boot, also ensure you have lingering enabled for the user. ``` $ cat ~/.config/containers/systemd/t1.container [Container] Image=quay.io/libpod/testimage:20240123 Exec=ip addr
[Install] WantedBy=default.target ``` As long as the container uses the default network or any bridge network it should always correctly start now as before it was racy depending on how long network setup took on the host. See the issue for more details. Then reboot
I will write up the test case and I would humbly request you to have a look :)
Wiki : http://fedoraproject.org/wiki/Test_Day:2024-11-01_Podman_5.3 results : https://testdays.fedoraproject.org/events/203
I cant make the quadlet test case to work .. any advice?
the first TC is ready for review : https://fedoraproject.org/wiki/QA:Testcase_pasta_container_internal
LGTM
What exactly? You will have to loginctl enable-linger $UID to ensure the user session starts on boot and then have the WantedBy=default.target in the quadlet to ensure the service is started at boot. This used to fail on 5.2 sometimes depending on your network environment, note that this is race condition not everyone will be able to reproduce. I managed to have a solid reproducer in a libvirt VM where I changed the network adapters MAC address when it was shut down to force new dhcp lease which was slow enough in my test cases.
loginctl enable-linger $UID
WantedBy=default.target
Also the blog post I mentioned https://blog.podman.io/2024/10/podman-5-3-changes-for-improved-networking-experience-with-pasta/ but that does not include any steps to reproduce.
the first TC is ready for review : https://fedoraproject.org/wiki/QA:Testcase_pasta_container_internal LGTM I cant make the quadlet test case to work .. any advice? What exactly? You will have to loginctl enable-linger $UID to ensure the user session starts on boot and then have the WantedBy=default.target in the quadlet to ensure the service is started at boot. This used to fail on 5.2 sometimes depending on your network environment, note that this is race condition not everyone will be able to reproduce. I managed to have a solid reproducer in a libvirt VM where I changed the network adapters MAC address when it was shut down to force new dhcp lease which was slow enough in my test cases. Also the blog post I mentioned https://blog.podman.io/2024/10/podman-5-3-changes-for-improved-networking-experience-with-pasta/ but that does not include any steps to reproduce.
It works finally, I missed the enable-linger ... anyway, the test case is https://fedoraproject.org/wiki/QA:Testcase_pasta_quadlet
Log in to comment on this ticket.