d22a42858f
The existing `SnapshotProvider` interface does not sufficiently lend itself to reliable persistence of snapshot data. For example, consider the following: - The deployment engine creates a resource - The snapshot provider fails to save the updated snapshot In this scenario, we have no mechanism by which we can discover that the existing snapshot (if any) does not reflect the actual state of the resources managed by the stack, and future updates may operate incorrectly. To address this, these changes split snapshotting into two phases: the `Begin` phase and the `End` phase. A provider that needs to be robust against the scenario described above (or any other scenario that allows for a mutation to the state of the stack that is not persisted) can use the `Begin` phase to persist the fact that there are outstanding mutations to the stack. It would then use the `End` phase to persist the updated snapshot and indicate that the mutation is no longer outstanding. These steps are somewhat analogous to the prepare and commit phases of two-phase commit. |
||
|---|---|---|
| .. | ||
| deploy.go | ||
| destroy.go | ||
| engine.go | ||
| env.go | ||
| events.go | ||
| eventsink.go | ||
| pack.go | ||
| plan.go | ||
| preview.go | ||