[RFE] improve role's declarative structure

[thom311]

The role aims to accept the desired networking configuration in a declarative way. The user doesn't say to issue a certain command or series of steps (like nmcli). Instead, the user describes the desired outcome in a declarative way, and the role makes it happen (depending on the configured provider).

This is the case with the states present and absent. These states intend to only deploy persistent configuration on the host, but not actually changing the current networking configuration. Essentially they create/delete connection profiles in NetworkManager or write/delete ifcfg files. For these states, the order doesn't really matter (unless you specify the same profile more then once -- "same" in the sense of having the same name).

Then there are the states up and down, which basically translate to nmcli connection up|down or ifup|ifdown calls. For NetworkManager provider, the order in which you activate/deactivate a set of profiles shouldn't matter too much. NetworkManager should make it happen correctly, in either order. That might not be entirely true, for example if you activate a slave connection first or after the master, makes an actual difference. For initscripts, this is much more a problem though. The role doesn't really know what the current state of the system is, and neither do the initscripts. It essentially leaves the decision of getting the right order for calling ifup to the user.

Currently, the order is the same as specified in the playbook. This should be improved. The user should just say which profiles should be up/down, and the role should figure out how to get that desired outcome (and in which order to call ifup/nmcli connection up).

See also the variable force_state_change. The role should become smarter about this, so that we require it less.

See also bug https://bugzilla.redhat.com/show_bug.cgi?id=1508614

[thom311]

Also note: issuing a nmcli connection up always means that, if the profile is already up, it goes first down and then up again. This is to do a full down-up cycle to fully re-initialize the configuration.

The role is already smart enough, that if the profile is already active, it dos nothing. See also: force_state_change option. TODO: see if this works all as expected, and possibly add tests.

Note that the mere fact that a profile is currently active does not yet mean that a profile didn't change in the meantime (since it was activated). If a profile gets modified while being active, the changes do not take effect immediately. NetworkManager allows to query the current device's configuration via GetAppliedConnection(). Maybe, the role should first query the currently applied connection, compare it to the current values of the profile, and determine more intelligently, whether the device needs to be re-activated. Or maybe, NetworkManager should get a new D-Bus API to simply check whether the applied configuration diverged from the profile (since it was activated).

Also, maybe the role should make use of the Reapply call. This is a more graceful variant of doing a full activation. It can only apply certain changes, and will error out if the changes are too large and require a full re-activation. The role should first try to do a reapply, and if that fails to do a full activation.