GNOME Bugzilla – Bug 760884
Expose AppliedConnection for devices on D-Bus
Last modified: 2016-02-16 10:35:13 UTC
NM always had the logical connotation of an "applied connection" -- contrary to the "settings connection". That is because when you modified a currently active connection, it was implied that the settings don't get applied until you re-activate the connection. Since bug 724041, this is also properly implemented by core daemon. Now we have the Reapply D-Bus command to update the applied-connection (bug 758463). Thus the "applied connection" is a integral part of how NM models settings and activating connections. It should also be exposed to the user via D-Bus. Currently the user doesn't know whether the currently applied connection (still) matches the referenced settings connection. For that, we should add a D-Bus function NMActiveConnection:GetAppliedConnection() which returns the connection hash. Note that exposing the applied connection this way, is much more lightweight then we do for settings-connection (where a settings-connection has it's own D-Bus object, and NMActiveConnection references only the D-Bus object path. The implementation is pretty simple and we should not release 1-2 (and Reapply API) without it.
need also bug 761714
please review: th/device-applied-connection-bgo760884
I think we need to make it clearer what the Applied Connection really is and how it relates to the Settings Connection and the device's IP4Config and IP6Config. I don't think the documentation makes it clear enough. For example, the Reapply() docs don't say anything about settings connections or applied connections, but now they should. We should document what happens when you pass a connection dict in Reapply(); I assume it updates the *applied* connection and the docs should say that. They should also say that this makes the applied connection different than the settings connection. Otherwise, the docs about "version_id" here don't make a lot of sense. I think we should also clarify the relationship to the ActiveConnection (which is really the SettingsConnection) too. That has the pointer to the settings connection, but I don't think the docs really say this. That would help people understand what the Applied and Settings connections are. We should also make it clearer why a user should care that a version-id might not match. What would cause that? eg, something like if two applications modify the device's configuration with Reapply() in close succession, they may not have an up-to-date idea of the device's configuration. The version-id prevents one application from overwriting the configuration that a different application applied to the device without reading that configuration first.
(In reply to Dan Williams from comment #3) > I think we need to make it clearer what the Applied Connection really is and > how it relates to the Settings Connection and the device's IP4Config and > IP6Config. I don't think the documentation makes it clear enough. Described now in Reapply() > For example, the Reapply() docs don't say anything about settings > connections or applied connections, but now they should. added to Reapply() > We should document what happens when you pass a connection dict in > Reapply(); I assume it updates the *applied* connection and the docs should > say that. They should also say that this makes the applied connection > different than the settings connection. Otherwise, the docs about > "version_id" here don't make a lot of sense. done. > I think we should also clarify the relationship to the ActiveConnection > (which is really the SettingsConnection) too. That has the pointer to the > settings connection, but I don't think the docs really say this. That would > help people understand what the Applied and Settings connections are. added commit "introspection: document the meaning of active connections", but apart from that, Reapply/GetAppliedConnection doesn't have much to do with active connections. > We should also make it clearer why a user should care that a version-id > might not match. What would cause that? eg, something like if two > applications modify the device's configuration with Reapply() in close > succession, they may not have an up-to-date idea of the device's > configuration. The version-id prevents one application from overwriting the > configuration that a different application applied to the device without > reading that configuration first. Correct. I tried to explain that. How about now?
merged as https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=a058cf41dc8dd6f952c4652ae689f3ed8ac042d6