summaryrefslogtreecommitdiff
path: root/doc/todo/onChange_failure_handling.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'doc/todo/onChange_failure_handling.mdwn')
-rw-r--r--doc/todo/onChange_failure_handling.mdwn41
1 files changed, 41 insertions, 0 deletions
diff --git a/doc/todo/onChange_failure_handling.mdwn b/doc/todo/onChange_failure_handling.mdwn
new file mode 100644
index 00000000..46a81caf
--- /dev/null
+++ b/doc/todo/onChange_failure_handling.mdwn
@@ -0,0 +1,41 @@
+> Please consider the following three properties
+> - p1,
+> - p2 and
+> - p3 = onChange p1 p2.
+>
+> If p1 returns MadeChange and p2 FailedChange, then p3 is FailedChange.
+> If we apply this property again without any changes, then p3 is
+> NoChange.
+>
+> This behavior could create problematic situations since p3 can be
+> required by another property which thinks that p3 has been applied
+> whereas it's not the case...
+>
+> -- Antoine
+
+Very well stated.
+
+I looked over existing uses of onChange in propellor, and many of them
+seem safe.
+
+The safe ones are where there's eg, a daemon, with a Property that it's
+running, and another Property that configures it in some way with
+onChange restart. If the restart fails, then the daemon is presumably
+left not running (unless it failed to stop the daemon somehow); a state
+that the former Property will attempt to take care of (or at least
+continue to indicate failure on) the next time propellor runs.
+
+Hmm, there are also lots of uses of onChange reloaded. If the new
+configuration of a daemon is broken, this can fail to reload it, and
+leave the daemon running with the old configuration. So that's more
+problimatic, and then there are some more problimatic yet uses of
+onChange, like the one that runs apt-get update after a change to
+sources.list.
+
+--[[Joey]]
+
+----
+
+The `onChangeFlagOnFail` combinator is a safer alternative to `onChange`
+that avoids this problem. But, it can be difficult to come up with unique
+names for the flag files it uses.