Skip to content

[th/fix-ipv6_check_addr_order] update version tags for @ipv6_check_addr_order test

Thomas Haller requested to merge th/fix-ipv6_check_addr_order into main

  1. enable the test also on rhel-8.5 (1.32.10). The version of the test which runs against older NM versions was always intended to check the actual behavior. I think on 8.5 the behavior was such, that the test should pass.

  2. 1.36.0 (and rhel-8.6, rhel-9.0) have a bug where they basically don't change the address order of existing addresses. The order/priority depends on the order in which addresses get added. This means, as addresses appear at different times (SLAAC before DHCPv6), that the order only depends on this accidental happening. Still, the effect is that this looks mostly like in rhel-8.5. It is however a bug, because NM would not rectify the order of addresses.

  3. note that internal Z-stream versions for rhel-8.5 (1.36.0-5.el8_6 and 1.36.0-6.el8_6) would accidentally fix the bug (1), and enforce the address order. This was also fixed on nm-1-36 branch ([1]). However, there is a different bug in the 1.36 series ([2]), that NetworkManager would prefer SLAAC over DHCPv6. If NM now enforces the order, that other bug appears and the order is wrong. This will be fixed in versions NetworkManager-1.36.0-7.el8_6 again, by not adjusting the order (wrongly). This wrong behavior has no CI test, it was only a temporary behavior.

  4. upstream 1.38.0+ and main have fixed all of this. The order is enforced and correct. Actually, the real fixes happened in upstream 1.37.91, 1.38.0, 1.39.2. However, those versions are no longer tested because we only test "nm-1-38" and "main" branches, which all have the new behavior. Simplify the version tags to account for that. It means, if you were to test 1.37.92, then the tags would be wrong. But that is not something were are going to do are care about.

  5. rhel-8.7 and rhel-9.1 has 1.39.0, however it currently has patches which reverts part of the fix. So the order there is wrong again. But we need to fix that. This change already adjusts the version tags as it will be in the future. That means, in the first moment, the development packages for 8.7 and 9.1 will fail this test.

[1] NetworkManager@cd460180 [2] NetworkManager#1021 (closed)

Merge request reports