summaryrefslogtreecommitdiff
path: root/introspection
diff options
context:
space:
mode:
authorThomas Haller <thaller@redhat.com>2018-03-28 08:09:56 +0200
committerThomas Haller <thaller@redhat.com>2018-04-04 14:02:13 +0200
commit6f0609088efb3f351fbbd6a267cf3fad7ab03b50 (patch)
treec084b9d71667d8bdb8617e36cc965ee437ee751f /introspection
parent2186a73cf66f3204ad20b4de46c20c5708e14373 (diff)
checkpoint: allow resetting the rollback timeout via D-Bus
This allows to adjust the timeout of an existing checkpoint. The main usecase of checkpoints, is to have a fail-safe when configuring the network remotely. By allowing to reset the timeout, the user can perform a series of actions, and keep bumping the timeout. That way, the entire series is still guarded by the same checkpoint, but the user can start with short timeout, and re-adjust the timeout as he goes along. The libnm API only implements the async form (at least for now). Sync methods are fundamentally wrong with D-Bus, and it's probably not needed. Also, follow glib convenction, where the async form doesn't have the _async name suffix. Also, accept a D-Bus path as argument, not a NMCheckpoint instance. The libnm API should not be more restricted than the underlying D-Bus API. It would be cumbersome to require the user to lookup the NMCheckpoint instance first, especially since libnm doesn't provide an efficient or convenient lookup-by-path method. On the other hand, retrieving the path from a NMCheckpoint instance is always possible.
Diffstat (limited to 'introspection')
-rw-r--r--introspection/org.freedesktop.NetworkManager.xml21
1 files changed, 21 insertions, 0 deletions
diff --git a/introspection/org.freedesktop.NetworkManager.xml b/introspection/org.freedesktop.NetworkManager.xml
index 26a618c1b..b8ad5911f 100644
--- a/introspection/org.freedesktop.NetworkManager.xml
+++ b/introspection/org.freedesktop.NetworkManager.xml
@@ -252,6 +252,27 @@
</method>
<!--
+ CheckpointAdjustRollbackTimeout:
+ @add_timeout: number of seconds from ~now~ in which the
+ timeout will expire. Set to 0 to disable the timeout.
+ Note that the added seconds start counting from now,
+ not "Created" timestamp or the previous expiration
+ time. Note that the "Created" property of the checkpoint
+ will stay unchanged by this call. However, the "RollbackTimeout"
+ will be recalculated to give the approximate new expiration time.
+ The new "RollbackTimeout" property will be approximate up to
+ one second precision, which is the accuracy of the property.
+
+ Reset the timeout for rollback for the checkpoint.
+
+ Since: 1.12
+ -->
+ <method name="CheckpointAdjustRollbackTimeout">
+ <arg name="checkpoint" type="o" direction="in"/>
+ <arg name="add_timeout" type="u" direction="in"/>
+ </method>
+
+ <!--
Devices:
The list of realized network devices. Realized devices are those which