Updates, Operations, Domain replication and Undo
Note: read this thread first: Re: Terminology around Domain changes
The domain and host models are represented by an object model which is maintained within each server node. This object model supports (un)marshalling to/from XML as well as regular serialization. In addition the object model can be mutated by way of model updates which apply to a domain or host model, depending on the update type. The updates are also XML- and Java-serializable.
Change replication from domain controller ("DC") to server instances should be incremental; thus model updates are the natural mechanism to do so. This implies a log of changes such that when a server manager ("SM") comes online, it can "play forward" all the changes that have occurred since the last time it communicated with the DC. Alternatively, if the changes are too numerous then the model can simply be resynced in whole
This mechanism, plus certain requirements, imply that we have a log of all changes that have occurred to the domain or host models going back for some time. This also implies that it is not a great stretch to allow reverting the domain and/or host state in the event of an administration problem.
I checked over all the requirements though, and this is never explicitly mentioned (though certain requirements state that we need to keep an audit log of changes, we need the ability to roll back deployments in particular, and we need the ability to roll back patches).
So now for the questions.
- Do we support undoing arbitrary operations? If yes, then each operation will be logged alongside a "compensating" operation which undoes that operation, plus a small amount of validation to make sure that some conflicting change hasn't occurred in the meantime.
- If not, do we support linearly rolling back the whole update state of a model (in other words, rather than arbitrary operations being revertable, we roll back the whole log to some past point)? If yes, then the same log changes apply except the validation bits are not needed.
- If not, then we still have to at least support reverting a deployment operation, so we need a separate way to track those in this case.
As discussed before, only the domain controller needs to have the full state of the domain (and, in this case, also any additional update state for reverting changes), though it is not clear at the current time if or how the total domain model content can be trimmed in practice.
Additional questions. Should runtime operations also be logged? I see the use for audit purposes but I don't think that it's realistic to expect to undo such operations (as I've said in other threads).
