You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The states present and absent are supposed to only deply/remove the persistant networking profiles on the host. They are not supposed to actually change the networking in any way. That is what the states up and down are for.
For initscripts, this is rather trivially the case, because the present/absent states just ensure that the ifcfg files are there or absent.
For NetworkManager, it's more complicated.
deleting a profile that is currently active causes the device to go down. That is, because in NetworkManager an active device must always have a profile. The solution in 1.10 is Update2() with the NM_SETTINGS_UPDATE2_FLAG_VOLATILE flag. Volatile means, that the connection is in-memory only, and will be automatically deleted once it goes down. If you make a connection volatile that currently is not active, it will be deleted right away.
adding or modifying a profile might always make it a candidate for autoconnecting. For state present, we would like to add/modify the profile without any changes. For that, 1.10 supports Update2() flag NM_SETTINGS_UPDATE2_FLAG_BLOCK_AUTOCONNECT. That works for the update case, but doesn't work for the add case. To add a connection that has connection.autoconnect=yes without activating it right away, we would either need new NetworkManager D-Bus API to block autoconnect form the start, or we first add the connection with connection.autoconnect=no, and then follow up with an Update2 call that sets connection.autoconnect=yes and uses NM_SETTINGS_UPDATE2_FLAG_BLOCK_AUTOCONNECT.
modifying the properties connection.metered or connection.zone takes effect immediately. There is currently no way to prevent that. NetworkManager should get a new flag for Update2 that allows to modify the profile and prevent these two properties from updating right away. Then, the role should use this new API.
The text was updated successfully, but these errors were encountered:
The states
present
andabsent
are supposed to only deply/remove the persistant networking profiles on the host. They are not supposed to actually change the networking in any way. That is what the statesup
anddown
are for.For initscripts, this is rather trivially the case, because the
present
/absent
states just ensure that the ifcfg files are there or absent.For NetworkManager, it's more complicated.
deleting a profile that is currently active causes the device to go down. That is, because in NetworkManager an active device must always have a profile. The solution in 1.10 is
Update2()
with theNM_SETTINGS_UPDATE2_FLAG_VOLATILE
flag. Volatile means, that the connection is in-memory only, and will be automatically deleted once it goes down. If you make a connection volatile that currently is not active, it will be deleted right away.adding or modifying a profile might always make it a candidate for autoconnecting. For state present, we would like to add/modify the profile without any changes. For that, 1.10 supports
Update2()
flagNM_SETTINGS_UPDATE2_FLAG_BLOCK_AUTOCONNECT
. That works for the update case, but doesn't work for the add case. To add a connection that hasconnection.autoconnect=yes
without activating it right away, we would either need new NetworkManager D-Bus API to block autoconnect form the start, or we first add the connection withconnection.autoconnect=no
, and then follow up with anUpdate2
call that setsconnection.autoconnect=yes
and usesNM_SETTINGS_UPDATE2_FLAG_BLOCK_AUTOCONNECT
.modifying the properties
connection.metered
orconnection.zone
takes effect immediately. There is currently no way to prevent that. NetworkManager should get a new flag forUpdate2
that allows to modify the profile and prevent these two properties from updating right away. Then, the role should use this new API.The text was updated successfully, but these errors were encountered: