RESTORE action assumptions
romanojd opened this issue · 5 comments
PROBLEM
The RESTORE action deletes and/or replaces files, settings, or attributes such that the state of the system is identical to its state at some previous time.
This makes some big assumptions about what previous state information is available.
POTENTIAL SOLUTION
No solution provided.
(Issue added on behalf of Jim Ronayne.)
I agree. This would only work if the actuator knew the restore point. Also, this should not be a requirement for all actuators to provide a restore capability.
Question: Is this action primarily for a remediation service to rebuild a system to a known good state or is this a more generic capability like an "undelete" or "undo"?
Most systems that support some form of RESTORE behavior also provide an identifier for a restore point. Examples: Virtual Machine Snapshot name, Windows restore point, etc.
Propose that a restore point identifier be a required modifier for the restore action. Restore without an identifier cannot be idempotent since repeated calls would just pop more and more restore points off the history stack. Restore point identifiers may be retrievable via a GET action.
That sounds like a good solution. We can add a required modifier called restore-to that specifies the restore point. Therefore, the assumption is that any device that can act on a RESTORE has the necessary state machine to restore to a specific point.
Sounds good to me. I recommend we assume the contents of the restore-to modifier are actuator-specific opaque tokens obtained from the actuator via a GET, QUERY, or as a part of a RESPONSE to a SAVE action.
One open question is then whether you want a handful of standard restore points that do not follow this convention and are always assumed to be valid, such as:
| Standard Restore Point | Description |
|---|---|
| HEAD | Most recently-saved restore point. Does not pop any restore points off the stack or tree. |
| last-known-stable | Last stable restore point known to execute properly. Pops all (unstable) newer restore points off the stack/tree branch, but retains last-known-stable itself. For systems that have no notion of a "stable" state, last-known-stable is synonymous with HEAD. |
I'll work this up into the next version of the the Language Description Document. I'll close this here and we can review the results in the next version of the document.