Config Management, part III: Rolling Back
In the previous part we looked how a micro language would look like, now I want to focus on what it means to roll back to a previous version. First take a look at an instruction that have no obvious reverse: CHMOD
When rolling back CHMOD you want to revert to the previous permissions. This would work automatically if there was an older CHMOD that would also set the permission, but in a lot of situations you probably just go with the (package) defaults. This implies you don’t know what a CHMOD reversal would be, and that implies we need to track that, like in a proper journal. As said each instruction has an implicit condition, if that condition doesn’t hold, it executes the instruction, we can utilize that state and save it in the journal. Let’s see in detail how this would work with something like CHMOD.
CHMOD⌗
Obviously we are going to check the permissions (or the mode) of the PATH:
Get mode => mode != MODE => CHMOD MODE PATH
To reverse this operation, we just need to save the mode somewhere, I can see something like the following: while executing each instruction generate the reverse and stash it somewhere. Of course we must be able to map the forward and backward change somehow.
So from the above:
Get mode => mode != MODE => CHMOD MODE PATH
||
|| (reverse)
\/
CHMOD mode PATH
How about just amending the journal file while we execute it, i.e. it goes from:
INSTRUCTION && ACTION
to INSTRUCTION && ACTION && REVERSE
, where the latter is optional. If that
information is not there the journal can’t be used to rollback. In the case of CHMOD, we’ll get
something like this:
CHMOD 644 /etc/coredns/Corefile && SYSCTL restart-or-reload coredns
which after this line has been processed and executed (assuming previous mode was 640):
CHMOD 644 /etc/coredns/Corefile && SYSCTL restart-or-reload coredns && CHMOD 640 /etc/coredns/Corefile
What remains is to write down how we actually go from Git commit aaa to bbb and back again and what that means for the journal.