summaryrefslogtreecommitdiff
path: root/doc/todo/onChange_failure_handling.mdwn
blob: 46a81cafdf4c3ba4c1fabef7c4892b5525fc2c2c (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
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.