Description of problem: http://tools.lab.eng.brq2.redhat.com/~vbenes/nm_ci_stats/stats.html#build:;search:bond_set_balance_slb_options <warn> [1678647741.3144] firewall: nft[106157]: command exited with status 1: (stderr: "/dev/stdin:5:34-46: Error: Could not process rule: File exists\012add set netdev nm-mlag-nm_2dbond macset-tagged { typeof ether saddr . vlan id; flags timeout; }\012 ^^^^^^^^^^^^^\012/dev/stdin:6:34-48: Error: Could not process rule: File exists\012add set netdev nm-mlag-nm_2dbond macset-untagged { typeof ether saddr; flags timeout;}\012 <info> [1678647741.3145] device (nm-bond): state change: ip-config -> failed (reason 'config-failed', sys-iface-state: 'managed') ^^^^^^^^^^^^^^^\012") Version-Release number of selected component (if applicable): RHEL-9.2.0-20230312.13 kernel-5.14.0-284.el9.x86_64 NetworkManager-1.43.3-31971.copr.9bf193f1a8.el9 but also: NM-1.42.2-1.el9
Created attachment 1961500 [details] reproducer (nft only)
workaround merged to NetworkManager: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/d3b54963622f242db1ebeda21dedd9558b484355 NetworkManager is expected to pass @bond_set_balance_slb_options with 1.43.6+
Reopening and assigning back to NetworkManager. There is an issue here, as a test failed. As the issue is with NetworkManager, the bug needs to move back so that it can be tested and properly tracked. This should be fixed by https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/d3b54963622f242db1ebeda21dedd9558b484355 ; NetworkManager-1.43.7+. Btw, where is this behavior about "dynamic" documented? It's not clear to me how it works. Also, I got those NFT rules from the existing SLB shell script which had the same issue. So there seems to be a usability/documentation problem, when even the experts get this wrong.
Hi Thomas, (In reply to Thomas Haller from comment #12) > Reopening and assigning back to NetworkManager. > > There is an issue here, as a test failed. As the issue is with > NetworkManager, the bug needs to move back so that it can be tested and > properly tracked. > > This should be fixed by > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/ > d3b54963622f242db1ebeda21dedd9558b484355 ; NetworkManager-1.43.7+. Change looks fine to me. > Btw, where is this behavior about "dynamic" documented? It's not clear to me > how it works. Also, I got those NFT rules from the existing SLB shell script > which had the same issue. So there seems to be a usability/documentation > problem, when even the experts get this wrong. Upstream docs are incomplete and inconsistent (from a short assessment). In general: If you want to change a set from packet path (i.e., via add/update statements), the set must be created with 'dynamic' flag. The bug you found is in nft's attempt at adding that flag automatically if it restores a ruleset which also contains an add/update statement. It has been fixed upstream meanwhile, but I would consider not specifying 'dynamic' flag in sets which shall be changed from a rule a bug in the first place.
(In reply to Phil Sutter from comment #14) > > Upstream docs are incomplete and inconsistent (from a short assessment). In > general: [...] thanks for elaborating!
dropping "zstream?" flag from comment 6. So far, no Z-stream is planned for this issue for NetworkManager (which still might happen).
we cannot see any failure in 1.43.10-1.el9.x86_64