diff options
| author | Thomas Haller <thaller@redhat.com> | 2018-10-17 11:33:02 +0200 |
|---|---|---|
| committer | Thomas Haller <thaller@redhat.com> | 2018-10-17 12:36:43 +0200 |
| commit | e86e73dd961959060503530d8b847eb8df7b2b2e (patch) | |
| tree | 73e84130ee21c8daa1ac5835d23cb9baeb92dd11 /data | |
| parent | 12bf77685b1c4550cf7e6ea10a947694efc1e5d7 (diff) | |
| download | NetworkManager-th/device-availability.tar.gz | |
core: ignore unmanaged devices for explicit activation request with multi-connectth/device-availability
When a device is unmanaged, an explicit activation request can
still activate it.
In particular, that is the case for
nmcli connection up "$PROFILE" ifname "$DEVICE"
It is also the case, for
nmcli connection up "$PROFILE"
alone, where NetworkManager searches for a suitable device.
Previously, that would also always consider unmanaged devices
as suitable candidates. I think that makes sense, as usually
a profile is strictly tied to a device via matches like
"connection.interface-name".
However, for profiles with "connection.multi-connect" not "single",
it seems this behavior is not best. Here, the profile is commonly
not tied to one device, but multiple. So, we probably should not
consider unmanaged devices as suitable candidates.
Change the behavior for such profiles. Note, that now the behavior
differs depending on "connection.multi-connect", which can be seen as
inconsistancy. I think it is preferable, because exactly a
multi-connect "single" profile indeed should be tied to one device.
Which is for example what `nmcli connection add` suggest, by requiring
an "ifname" argument. If the profile is tied to a device, the user's
intent is clear and it should not require an explict
nmcli device set "$DEVICE" managed yes
call first.
https://bugzilla.redhat.com/show_bug.cgi?id=1639254
Diffstat (limited to 'data')
0 files changed, 0 insertions, 0 deletions
