Description of problem: connection.secondaries not updated after secondary connection removal, keeping stale UUID's there Version-Release number of selected component (if applicable): NetworkManager-1.42.2-1.el9.x86_64 How reproducible: always Steps to Reproduce: 1. have a connection with empty connection.secondaries and an e.g. VPN connection 2. Add VPN connection to base's connection.secondaries 3. delete VPN connection Actual results: UUID of a deleted VPN connection is still in base connection's connection.secondaries Expected results: UUID of deleted secondary connection is deleted from respective base connections' connection.secondaries entries Additional info: Already covered by NMCI scenario connection_secondaries_are_cleared_after_removal in the linked MR. sort of similar situation is in controller/port connections, however there may be NM users depending on the current behaviour: $ nmcli c add con-name bond0+ ifname bond0 type bond connection.autoconnect no Connection 'bond0+' (619ef611-14f1-47e6-92cf-c580727a28dd) successfully added. $ nmcli c add con-name bond0.10+ ifname eth10 type ethernet connection.autoconnect no master bond0+ Connection 'bond0.10+' (c6f2b280-26f1-42c3-bc50-4f475ee6a819) successfully added. $ UUID=$(nmcli -g connection.uuid c s bond0+) $ nmcli -f all c s bond0.10+ | grep "$UUID\|bond0+" connection.master: 619ef611-14f1-47e6-92cf-c580727a28dd $ nmcli c del bond0+ Connection 'bond0+' (619ef611-14f1-47e6-92cf-c580727a28dd) successfully deleted. $ nmcli -f all c s bond0.10+ | grep "$UUID\|bond0+" connection.master: 619ef611-14f1-47e6-92cf-c580727a28dd $
> however there may be NM users depending on the current behaviour Doing this as an unconditional change would clash with internal NM architecture and doing it just for secondaries would bring inconsistent behaviour. Therefore I'm self-closing this bug. In the future, I may write a feature request for an option to "nmcli c delete" which could be the same for any similar relationships and could be implemented just in NM clients (libnm, nmcli...).
Closing this bug based on comment 1. Thanks David.