From a8de302eab9ae9916a67b52ddcae2e4e2df1fe7a Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 21 Jul 2015 11:13:21 -0400 Subject: open todo item --- doc/todo/onChange_failure_handling.mdwn | 35 +++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 doc/todo/onChange_failure_handling.mdwn (limited to 'doc/todo/onChange_failure_handling.mdwn') diff --git a/doc/todo/onChange_failure_handling.mdwn b/doc/todo/onChange_failure_handling.mdwn new file mode 100644 index 00000000..1c326415 --- /dev/null +++ b/doc/todo/onChange_failure_handling.mdwn @@ -0,0 +1,35 @@ +> 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]] -- cgit v1.2.3