Thist proposal would be really beneficial and befitting to the oVirt network management paradigm. Especially points 1 and 2, since they directly map to actions that we offer right now in our webadmin portal.

4) Optional: Accepting changes from Netlink made by other tools

5) Optional: Accepting configuration made before NetworkManager is started

*** Bug 690352 has been marked as a duplicate of this bug. ***

6) Distinction between own/unowned connections (formerly managed/unmanaged), as a connection that is owned by NetworkManager would e.g. dispose of its virtual interface, while a temporary connection that just follows the changes (but could be used to make some changes) would leave the interface there, as it doesn't belong to NetworkManager.

Consolidating from other bug reports...

 David Jaša [reporter] 2012-07-31 14:33:19 UTC

Manage interface set up outside of NM on user/admin request

This is an extension of . Essentially, this is good for situations when user
sets up L1/L2 connection details manually (by creating a bridge or running
wpa_supplicant manually for instance) but wants NM to take care of connection
on IP level.

 David Jaša [reporter] 2012-07-31 14:32:32 UTC

Observe passively interfaces created outside network manager.

Why:
The long standing woe of NM is it's inability to take not-yet-supported devices
into account like bridges etc. The result is that in such cases, NM is either
told not to interfere (NM_CONTROLLED=no in ifcfg-rh scripts) or outright
disabled.

In first case, this behaviour leads to upper layer errors like apps thinking
they're offline despite being online etc, in second case, it harms NM adoption.

Proposed fix:
1) Watch status of all network devices, no matter if they're being managed by
NM or not
2) manage nm-managed devices using all available information (e.g.: eth0 is
bridged into br0 and not nm-controlled, wlan0 is nm-controlled - NM should add
default route to wlan0 if it is removed from br0 but once br0 comes back
online, NM shouldn't "steal" default route from it)
3) report network availability to other programs based on such "complete
picture" so that apps that rely on NM for network availability can learn that
network is available albeit through non-nm-controlled interface

Notes:
this seems to me distinct to bug 589092 which is about honoring manual changes
to NM-controlled interfaces.

*** Bug 680908 has been marked as a duplicate of this bug. ***

*** Bug 589092 has been marked as a duplicate of this bug. ***

(In reply to comment #0)
> 1) Creating a (temporary) connection

This is possible with D-Bus (o.fd.NM.Settings.AddConnectionUnsaved) and libnm-glib (nm_remote_settings_add_connection_unsaved()). It appears to be possible in nmcli when using the interactive connection editor ("save temporary"), but not when using "nmcli con add"...

> 2) Making a temporary connection permanent

o.fd.NM.SettingsConnection.Save / nm_remote_connection_save()

> 3) Optional: Making a permanent connection temporary

There is no explicit API for this, but you can delete the permanent one and then recreate it temporary (though that would cause any active instance of it to be disconnected).

(In reply to comment #2)
> 4) Optional: Accepting changes from Netlink made by other tools

This is bug 697370 and potentially applies to both temporary and permanent connections.

(In reply to comment #3)
> 5) Optional: Accepting configuration made before NetworkManager is started

This is already done; NM creates temporary connections representing the startup state of each device (if it can't find a permanent connection that matches it).

(In reply to comment #5)
> 6) Distinction between own/unowned connections (formerly managed/unmanaged), as
> a connection that is owned by NetworkManager would e.g. dispose of its virtual
> interface, while a temporary connection that just follows the changes (but
> could be used to make some changes) would leave the interface there, as it
> doesn't belong to NetworkManager.

Currently NM will delete devices on disconnect only if it originally created the device. (More or less.) I don't think there's any way to flip the behavior in either direction though.

(In reply to comment #9)
> > 4) Optional: Accepting changes from Netlink made by other tools
> 
> This is bug 697370 and potentially applies to both temporary and permanent
> connections.

oops, no, that's the wrong direction. There is a bug for this though...

(In reply to comment #9)
> (In reply to comment #0)
> > 1) Creating a (temporary) connection
> 
> This is possible with D-Bus (o.fd.NM.Settings.AddConnectionUnsaved) and
> libnm-glib (nm_remote_settings_add_connection_unsaved()). It appears to be
> possible in nmcli when using the interactive connection editor ("save
> temporary"), but not when using "nmcli con add"...

that works too:
  $ nmcli connection add save no ...

Most of this bug is done, I'd like to redirect this bug to this one item now:

> 3) Optional: Making a permanent connection temporary

There is no explicit API for this, but you can delete the permanent one and
then recreate it temporary (though that would cause any active instance of it
to be disconnected).

We can discuss if this is useful behavior or not and prioritize as appropriate.

bugzilla.gnome.org is being shut down in favor of a GitLab instance. 
We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time.

If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/

Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).