A question on Pulumi checkpoints... From the <docs...
# general
c
A question on Pulumi checkpoints... From the docs: "_The Pulumi Cloud backends records every checkpoint so that it is possible to recover from exotic failure scenarios. Self-managed backends may have more trouble recovering from these situations as they typically store a singular Pulumi state file._" I'm using self-managed backend (S3). An update of a large stack takes hours, but I can do it in couple of minutes with
PULUMI_EXPERIMENTAL=1 PULUMI_SKIP_CHECKPOINTS=true
. If my backend " _typically store a singular Pulumi state file_", what makes such a huge difference?
b
The gist of this is that by default we write a checkpoint for every resource that gets updated. This means we know exactly what’s going on at the time. With the skip checkpoint env var set to true, we just write once when everything is done so you don’t get the tracking that you would otherwise.
c
Yup, I understand that part. Then what does it mean that self-managed backends "_typically store a singular Pulumi state file._"? Since I'm using S3 bucket backend, then
PULUMI_EXPERIMENTAL=1 PULUMI_SKIP_CHECKPOINTS=true
should not make a difference for me. But it does. Big time. Hours vs. minutes kind of difference. Why?
b
Because we’re updating that file multiple times (per checkpoint) during the update as opposed to once
c
Then the self-managed backend is written multiple times (per checkpoint), and the statement in the docs "_typically store a singular Pulumi state file._" is misleading, right?
b
No, we’re writing to the same single file multiple times
c
Ah, OK, that makes sense. Thanks!