Age | Commit message (Collapse) | Author | Files | Lines |
|
Open vSwitch is the special kid on the block -- it likes to be in charge of
the link lifetime and so we shouldn't be. This means that we shouldn't be
attempting to remove the link: we'd just (gracefully) fail anyways.
More importantly, this also means that we shouldn't care if we see the link
go away. Once the device reaches DISCONNECTED state, its configuration is
cleaned up and we may already be activating another connection. We shouldn't
alter the device state when OpenVSwitch decides to drop the old link.
https://bugzilla.redhat.com/show_bug.cgi?id=1543557
|
|
If we surprise-remove the master, slaves would immediately attempt to bring
things up by autoconnecting. Not cool. Policy, however, blocks
autoconnect if the slaves disconnect due to "dependency-failed", and it
indeed seems to be an appropriate reason here:
$ nmcli c add type bridge
$ nmcli c add type dummy ifname dummy0 master bridge autoconnect yes
$ nmcli c del bridge
$
Before:
(nm-bridge): state change: ip-config -> deactivating (reason 'connection-removed')
(nm-bridge): state change: deactivating -> disconnected (reason 'connection-removed')
(nm-bridge): detached bridge port dummy0
(dummy0): state change: activated -> disconnected (reason 'connection-removed')
(nm-bridge): state change: disconnected -> unmanaged (reason 'user-requested')
(dummy0): state change: disconnected -> unmanaged (reason 'user-requested')
policy: auto-activating connection 'bridge-slave-dummy0'
After:
(nm-bridge): state change: ip-config -> deactivating (reason 'connection-removed')
(nm-bridge): state change: deactivating -> disconnected (reason 'connection-removed')
(nm-bridge): detached bridge port dummy0
(dummy0): state change: activated -> deactivating (reason 'dependency-failed')
(nm-bridge): state change: disconnected -> unmanaged (reason 'user-requested')
(dummy0): state change: deactivating -> disconnected (reason 'dependency-failed')
(dummy0): state change: disconnected -> unmanaged (reason 'user-requested')
https://github.com/NetworkManager/NetworkManager/pull/319
|
|
https://github.com/NetworkManager/NetworkManager/pull/317
|
|
set_fcn()
|
|
Setting one property might affect multiple properties.
For example, setting a team property might also emit property changed
signal for "team.config".
Or, one property might be modified multiple times. For example list
properties may first clear the property, then append multiple elements.
Or a list property might remove multiple elements.
Combine these signals via g_object_freeze_notify() and
g_object_thaw_notify().
|
|
editor_init_existing_connection() is
|
|
This workaround was dropped when refactoring the property handling.
Restore the workaround (at least) until libnm is fixed.
|
|
|
|
There is no reason to validate only in certain cases. Either we
validate, or we don't (always the same).
This is a change in behavior, but the cases should be sensible.
|
|
Most GObject properties default to FALSE/NULL/0. In that case, there
is no difference between setting the default or clearing the value.
During
if (_SET_FCN_DO_RESET_DEFAULT (property_info, modifier, value))
return _gobject_property_reset_default (setting, property_info->property_name);
it is correct to reset the default.
However for list-typed properties, we want to clear the list. So,
it should be
if (_SET_FCN_DO_SET_ALL (modifier, value))
_gobject_property_reset (setting, property_info->property_name, FALSE);
|
|
"match.interface-names" is the only property that uses VALUE_STRSPLIT_MODE_MULTILIST_WITH_ESCAPE.
$ nmcli connection modify "$PROFILE" match.interface-name ' 5, \,\ 4\, '
results in
[match]
interface-name=5;, ;4,;
and
$ echo ">$(nmcli -g match.interface-name -escape=no connection show "$PROFILE")<"
>5 \,\ 4\,<
Yes, plain --get leads to a wrong double-escaping:
$ echo ">$(nmcli -g match.interface-name connection show "$PROFILE")<"
>5 \\,\\ 4\\,<
|
|
The VFs already can be parsed as plain number (to indicate the
ifindex). We should not also support accepting the plain number
as index to be removed.
Fixes: a2f12994b7cd ('cli: add support for configuring SR-IOV')
|
|
|
|
|
|
|
|
$ nmcli connection modify "$PROFILE" -ipv4.addresses 1,3
Already before, nmcli would support removing items by index. But only
one number was supported.
- indexes are zero based (as before).
- duplicate indexes or indexes out of bounds are silently ignored.
Maybe certain properties should not support removal by index.
|
|
Use new ValueStrsplitMode "VALUE_STRSPLIT_MODE_STRIPPED".
Note that this is not exactly what we did before. For example, empty
tokens are now silently removed.
Also, we accept now whitespace as separators.
|
|
Have one function that gets all the nonesense right. "nonesense", because
we have inconsistent behaviors, and the function is supposed to help with
that.
|
|
|
|
set_fcn() and remove_fcn() are strongly related. They should accept
arguments in the same format, hence the parsing of the arguments should
be done at one place.
In fact, previously the parsing was separate, leading to ugly
inconsistencies:
$ nmcli connection modify "$PROFILE" +vpn.data x=y
$ nmcli connection modify "$PROFILE" -vpn.data x=y
Error: failed to remove a value from vpn.data: invalid option 'x=y'.
or
$ nmcli connection modify "$PROFILE" +ipv4.addresses 192.168.1.5/24,192.168.2.5/24
$ nmcli connection modify "$PROFILE" -ipv4.addresses 192.168.1.5/24,192.168.2.5/24
Error: failed to remove a value from ipv4.addresses: invalid prefix '24,192.168.2.5/24'; <1-32> allowed.
Let set_fcn() handle set-default, set-all, add, and subtract.
|
|
Previously, set_fcn() could only append values. Now, pass on the modifier
so that it may append, set all, or reset the default.
These operations are strongly related and should be handled by the same
set_fcn() function.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It's usually not necessary, because _nm_utils_unescape_spaces()
gets called after nm_utils_strsplit_set(), which already removes
the non-escaped spaces.
Still, for completeness, this should be here. Also, because with
this the function is useful for individual options (not delimiter
separate list values), to support automatically dropping leading or
trailing whitespace, but also support escaping them.
|
|
|
|
|
|
|
|
|
|
setting
|
|
|
|
|
|
|
|
A property-info can only have one property-typ-data. That means,
all functions (get_fcn(), set_fcn()) need to either take not
property-typ-data, or they must all accept the same.
That made it hard to mix _get_fcn_nmc_with_default() with setters
that do require a certain property-typ-data. Instead, move the
is_default_func() to the general portion, and let _get_fcn_gobject()
handle it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
nm_setting_wired_add_s390_option()
The setting's verify() function already checks that the s390 options
are not empty and no longer than 200. Asserting for that is a major
annoyance, because callers need to reimplement that check.
|
|
|
|
|
|
|