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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
|
Long ago, nomeata pointed out that RevertableProperty required the user to
keep track of different versions of a Host, in a way that should be able to
be automated. When the user decides to revert a RevertableProperty, they
have to keep the reverted property on the Host until propellor runs there,
and only then can remove it.
What if instead, there was a way to store the old version of a Host
somewhere. Let's not worry about where or how, but assume we have
`(old, new) :: (Host, Host)`
Propellor could compare `old` and `new`, and if it finds a
RevertableProperty in `old` that is not in `new`, add it in reverted form
to `new'`.
Also, if propellor finds a Property in `old` that is not in `new`, it can
tell the user that this Property needs to be reverted, but cannot be, so
`new` won't fully describe the state of the host. --[[Joey]]
----
There are a lot of ways such a capability could be used, especially if
there were a way to pull the old version of a Host out of a previous
version of config.hs or something like that. But leaving aside such magic,
here are some nice use cases:
* Suppose we want to generate several disk images, which are somewhat
similar, but differ in some properties. Rather than building a separate
chroot for each, we can build a chroot for the first, update the first
disk image, compare that with the second and update the chroot
accordingly, and so on.
* When propellor is used to build a OS installer disk image, that installer
could know the properties used to create it, and the properties of the
system that is desired to be installed. To install, it can rsync the
installer disk contents to `/target` and then run propellor in `/target`,
differentially updating it as needed.
----
Here's the catch: It can't be implemented currently! The comparison of
properties needs an `Eq` instance for Property (and RevertableProperty).
But, a property contains an action in the IO monad, which can't have an
`Eq` instance, and so there's no good way to compare properties.
Making propellor use an ESDL could get us `Eq`. But it would make it rather
clumsy to write properties, something like this.
<pre>
appendfoo f = WriteFile f (ListAppend "foo" (ReadFile f))
</pre>
(Perhaps a deeply embedded DSL would be better.)
Could a Free monad get us `Eq`? Well, there can apparently be free monads that
have an `Eq` instance, but I tried building one for a simple teletype, and
failed, which does not bode well. Here's the code; this fails to compile
because of a missing instance `(Eq1 ((->) String))`, and of course comparing
functions for equality is not generally feasible.
<pre>
{-# LANGUAGE FlexibleContexts, UndecidableInstances #-}
import Control.Monad.Free
import Prelude.Extras
data TeletypeF x
= PutStrLn String x
| GetLine (String -> x)
instance Functor TeletypeF where
fmap f (PutStrLn str x) = PutStrLn str (f x)
fmap f (GetLine k) = GetLine (f . k)
instance (Eq1 ((->) String)) => Eq1 TeletypeF where
PutStrLn a x ==# PutStrLn b y = a == b && x == y
GetLine a ==# GetLine b = a ==# b
type Teletype = Free TeletypeF
putStrLn' :: String -> Teletype ()
putStrLn' str = liftF $ PutStrLn str ()
getLine' :: Teletype String
getLine' = liftF $ GetLine id
foo :: Teletype ()
foo = do
putStrLn' "name?"
name <- getLine'
putStrLn' ("hello, " ++ name)
fooisfoo :: Bool
fooisfoo = foo ==# foo
</pre>
-----
## the best we can do without Eq
Is, perhaps:
data Version = A | B | C
deriving (Enum, Ord)
foo :: Versioned Hoso
foo = versionedHost "foo" $ do
ver A someprop
<|> othervers otherprop
ver A somerevertableprop
ver [B, C] newprop
That's ... pretty ok, would hit as least some of the use cases described
above. Seems to need a Reader+Writer monad to implement it,
without passing the Version around explicitly.
Is it allowable for `newprop` to not be revertable?
Once `foo` gets that property, it is never removed if we're moving only
forwards. On the other hand, perhaps the user will want to roll back to
version A. Allowing rollbacks seems good, so `inVersion` should only
accept `RevertableProperty`.
Another interesting case is this:
foo = versionedHost "foo" $ do
ver A bar
always otherprop
ver [B, C] bar
Is version A of foo identical to verion B? If so, this should be allowed to
compile even when `bar` cannot be reverted. On the other hand, perhaps
ordering of the properties matters, in which case the systems are subtly
different, and there's no way to get from A to B.
It's certianly possible for ordering to matter in propellor properties,
although it's generally a bug when it does. So, it seems ok for this
case to be rejected.
As well as `Versioned Host`, it would be possible to have
`Versioned (Property metatypes)`.
Indeed, that would make sense to he used internally in the
examples above. And that allows composition of properties with versioning:
someprop :: Versioned (Property DebianLike)
someprop = versionedProperty $ do
ver A foo <|> ver [B, C] bar
> [[done]] in Propellor.Property.Versioned. --[[Joey]]
|
