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.

appendfoo f = WriteFile f (ListAppend "foo" (ReadFile f))

(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.

{-# 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

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