mirror of
https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git
synced 2026-05-02 03:48:09 +02:00
98b3056604
When we have a bridge interface with ports attached externally (that is,
not by NetworkManager itself), then it can make sense that during
checkpoint rollback we want to keep those ports attached.
During rollback, we may need to deactivate the bridge device and
re-activate it. Implement this, by setting a flag before deactivating,
which prevents external ports to be detached. The flag gets cleared,
when the device state changes to activated (the following activation)
or unmanaged.
This is an ugly solution, for several reasons.
For one, NMDevice tracks its ports in the "slaves" list. But what
it does is ugly. There is no clear concept to understand what it
actually tacks. For example, it tracks externally added interfaces
(nm_device_sys_iface_state_is_external()) that are attached while
not being connected. But it also tracks interfaces that we want to attach
during activation (but which are not yet actually enslaved). It also tracks
slaves that have no actual netdev device (OVS). So it's not clear what this
list contains and what it should contain at any point in time. When we skip
the change of the slaves states during nm_device_master_release_slaves_all(),
it's not really clear what the effects are. It's ugly, but probably correct
enough. What would be better, if we had a clear purpose of what the
lists (or several lists) mean. E.g. a list of all ports that are
currently, physically attached vs. a list of ports we want to attach vs.
a list of OVS slaves that have no actual netdev device.
Another problem is that we attach state on the device
("activation_state_preserve_external_ports"), which should linger there
during the deactivation and reactivation. How can we be sure that we don't
leave that flag dangling there, and that the desired following activation
is the one we cared about? If the follow-up activation fails short (e.g. an
unmanaged command comes first), will we properly disconnect the slaves?
Should we even? In practice, it might be correct enough.
Also, we only implement this for bridges. I think this is where it makes
the most sense. And after all, it's an odd thing to preserve unknown,
external things during a rollback -- unknown, because we have no knowledge
about why these ports are attached and what to do with them.
Also, the change doesn't remember the ports that were attached when the
checkpoint was created. Instead, we preserve all ports that are attached
during rollback. That seems more useful and easier to implement. So we
don't actually rollback to the configuration when the checkpoint was
created. Instead, we rollback, but keep external devices.
Also, we do this now by default and introduce a flag to get the previous
behavior.
https://bugzilla.redhat.com/show_bug.cgi?id=2035519
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ # 909
|
||
|---|---|---|
| .. | ||
| meson.build | ||
| nm-connection.h | ||
| nm-core-types.h | ||
| nm-dbus-interface.h | ||
| nm-errors.h | ||
| nm-keyfile.h | ||
| nm-setting-6lowpan.h | ||
| nm-setting-8021x.h | ||
| nm-setting-adsl.h | ||
| nm-setting-bluetooth.h | ||
| nm-setting-bond-port.h | ||
| nm-setting-bond.h | ||
| nm-setting-bridge-port.h | ||
| nm-setting-bridge.h | ||
| nm-setting-cdma.h | ||
| nm-setting-connection.h | ||
| nm-setting-dcb.h | ||
| nm-setting-dummy.h | ||
| nm-setting-ethtool.h | ||
| nm-setting-generic.h | ||
| nm-setting-gsm.h | ||
| nm-setting-hostname.h | ||
| nm-setting-infiniband.h | ||
| nm-setting-ip-config.h | ||
| nm-setting-ip-tunnel.h | ||
| nm-setting-ip4-config.h | ||
| nm-setting-ip6-config.h | ||
| nm-setting-macsec.h | ||
| nm-setting-macvlan.h | ||
| nm-setting-match.h | ||
| nm-setting-olpc-mesh.h | ||
| nm-setting-ovs-bridge.h | ||
| nm-setting-ovs-dpdk.h | ||
| nm-setting-ovs-external-ids.h | ||
| nm-setting-ovs-interface.h | ||
| nm-setting-ovs-patch.h | ||
| nm-setting-ovs-port.h | ||
| nm-setting-ppp.h | ||
| nm-setting-pppoe.h | ||
| nm-setting-proxy.h | ||
| nm-setting-serial.h | ||
| nm-setting-sriov.h | ||
| nm-setting-tc-config.h | ||
| nm-setting-team-port.h | ||
| nm-setting-team.h | ||
| nm-setting-tun.h | ||
| nm-setting-user.h | ||
| nm-setting-veth.h | ||
| nm-setting-vlan.h | ||
| nm-setting-vpn.h | ||
| nm-setting-vrf.h | ||
| nm-setting-vxlan.h | ||
| nm-setting-wifi-p2p.h | ||
| nm-setting-wimax.h | ||
| nm-setting-wired.h | ||
| nm-setting-wireguard.h | ||
| nm-setting-wireless-security.h | ||
| nm-setting-wireless.h | ||
| nm-setting-wpan.h | ||
| nm-setting.h | ||
| nm-simple-connection.h | ||
| nm-utils.h | ||
| nm-version-macros.h.in | ||
| nm-version.h | ||
| nm-vpn-dbus-interface.h | ||
| nm-vpn-editor-plugin.h | ||
| nm-vpn-plugin-info.h | ||
| README.md | ||
libnm-core-public
This contains (mostly) header files only, which are also part of
the public API of libnm.
Also, this API is implemented by the static library libnm-core-impl,
which in turn is statically linked into NetworkManager core and libnm.
These headers can be used by anybody who either:
- links (statically) against
libnm-core-impl. - links dynamically against
libnm.
Note that there is also one source file: nm-core-enum-types.c.
This source file really belongs to libnm-core-impl but it is here
because it's a generated file and so far I couldn't figure out how
to generate nm-core-enum-types.h here while moving nm-core-enum-types.c
to libnm-core-impl.
Aside nm-core-enum-types.c, this directory only provides header files.
Users should add this directory (both srcdir and builddir) to the include
search path, because libnm users are used to include these headers unqualified
(like #include "nm-setting.h).