Re: [RFC] Revise NM behavior for Unmanaged Devices and Assuming Connections (bgo 746440)

On Mon, Nov 09, 2015 at 05:43:35PM +0100, Thomas Haller wrote:
The last_seen_timestamp is there to eventually garbage collect the
state entry. Note that we write a state-entry for every device we see.

Do we need to write a state-file entry also for devices that we see
but we don't (initially) manage? For example, if a veth appears, it is
a software device without any configuration and so NM will not manage
it. In that case is it useful to write a state-file entry?

When NM sees a new device, it will very early decide whether to manage
it (nm_device_finish_init()).

Preferably, we look at the statefile. If the statefile from a previous
NM run indicates whether the device should be mananged/unmanged, do it.
That means, when the user sets
  nmcli device eth0 set managed on|off
we will remember that decision in the statefile (yeay).

Sounds ok to me. Since we are adding another reason to unmanage
devices, it would be useful to have (I don't know if we already do) a
new property in the 'nmcli d show' output which tells why a device is

- Otherwise, and after `nmcli device set eth0 managed yes`, we search
for a connection to autoactivate. If we find one, we activate it
(gracefully). If not, transition to NM_DEVICE_STATE_DISCONNECTED /
UNAVAILALE including clearing the IP configuration so that the device
is truly disconnected. Especially, we don't try to activate the
generated-unmanaged-connection and we don't create any connections (as
we do currently).

In you proposal I like the fact that a user can explicitly
manage/unmanage a device.

About the new behavior for managed devices, probably it's easier to
understand (IIUC, either NM manages the device and therefore it
activates only on-disk connections on it; or it doesn't manage it and
then it only creates an in-memory connection to reflect the device

But maybe for many users it will be confusing that the new version of
NM will overwrite their manual configuration upon startup (for managed


Attachment: pgpXxDRsnw8IL.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]