Does it make sense to allow _any_ permanent configuration changes on a generated interface? IMO "generated" itself implies transient - so I wouldn't expect anything to persist.

From NetworkManager's point of view, when a device is not explicitly configured to be unmanaged, and if NetworkManager has currently no profile active on that device, the device lingers in state "disconnected" or "unavailable".

The reason why there is no profile active, is because 
  - no suitable profile was configured
  - no suitable profile was ready to autoconnect
  - no suitable profile was manually activated by the user (nmcli connection up)

Anyway, so assume the device lingers in state "disconnected" or "unavailable", and NetworkManager isn't doing anything about it. If somebody else starts configuring IP addresses, NetworkManager generates an in-memory profile and pretends that the interface is up. It's supposed not to interfere with this interface at all, because clearly somebody else (docker!) handles it. I find this behaviour rather odd, but I guess, it makes some sense to express on the API that something on this device is happening.


This generated profile can be modified like any other regular profile.

  $ nmcli connection modify docker0 connection.zone internal

This may also mean, that the in-memory profile gets now persisted to disk. On top of that, when such a profile is modified, NetworkManager takes that as command to take over managing the device gracefully. For example, previously the generated profile might be generated with ipv4.method=auto, but NetworkManager would not actually start a DHCP client. It was pretend-only. But when taking over managing, NetworkManager would be expected to actually start doing DHCP on the device.



Ok, it gets more complicated. Usually, when you modify a regular profile which is currently active on a device, this modification does not take effect immediately. Not until `nmcli device reapply` or full reactivation of the profile.
So, with respect of "taking over managing the interface" one would expect that if you have an externally generated interface and you do

  $ nmcli connection modify "$PROFILE" ethernet.mtu 1400

then NetworkManager would persist the profile and start to fully manage the device. But it should not change the MTU right away because you only modified the profile.

However, there is an exception: when you modify "connection.zone" and "connection.metered" properties of a profile which is currently active, these two properties take effect immediately. So, one would expect that indeed the zone changes right away.

  $ nmcli connection modify docker0 connection.zone internal
  $ firewall-cmd --get-active-zones
  internal
    interfaces: docker0




Btw, the docker0 bridge is managed by docker. It simply makes no sense to tell NetworkManager to interfere with this interface and the user is advised to leave the generated NetworkManager profile alone. However, the bug report does make sense

I see three options what we can do:

 1) fix "take over fully managing the device" to properly behave according to 
    what I described. In particular w.r.t. the firewall zone.
 2) NetworkManager should prevent modifying such a profile via D-Bus. 
    Care must be taken, that the user also cannot drop a profile with the same
    UUID to disk and modify the generated profile via `nmcli connection reload`
 3) stop generating these external profile at all, and leave the interface in
    state disconnected. I already wanted to do this, but opted out, because it
    was too big of a change in behaviour.

in terms of simplicity: 3 > 2 > 1
in terms of preserving established behaviour: 1 > 2 > 3

From my point of view #3 is what I expect, but I'm not familiar with NetworkManager's APIs and semantics. So I'll let the NM group decide the best path forward. :)

I agree with Eric above, especially the NM semantics.
For this bug however it is sufficient to not allow managing or reporting the profile zone, which on it's own might be ugly w.r.t. NM usage model.

In #3:
 * as a NM user I'd not be able to just modify and then save so-far-unmanaged interface, but that seems to be a corner use case to me.
 * there could be regression in not reporting all present interfaces via NM though.

An improvement for the oddities of externally managed devices would be bug 1650221: devices would be unmanaged by default unless the user creates a profile for them. That doesn't solve the oddities, but it avoids it in many cases where the user never intended NM to manage the device.

Related to improving handling of externally-managed devices is bug 1650228.

the advised way before messing with a device manually (which is not marked as unmanaged in NetworkManager) is to mark the device as unmanaged. When doing so, the device should be left to the user in a suitable state.

Mass-moving bugs RHEL <= 7.6.0 to 7.7.0.
As we are past RFE deadline for 7.7.0 and we should have no new features on 7.8.0, please evaluate if it's still wanted on RHEL7 and contact PM for exception. You may also move it to RHEL8 if that's wanted. Thanks!

See also discussion at https://bugzilla.redhat.com/show_bug.cgi?id=1542978

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

Opened bug 1816202 "Better represent externally managed devices in NetworkManager UI".

This also implies to make it possible to recognize these externally managed devices on D-Bus. That API may also be interesting for firewald to decide what (not) to do.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.