New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider adding a --save-final-state-only flag (or PULUMI_SKIP_CHECKPOINTS env var) to speed up large stacks #10668
Comments
|
@AaronFriel suggests using an environment variable rather than a CLI flag I prefer env vars over CLI flags as it works in users' favor and engineering's favor. users:
engineering:
an env var indicating a vague performance improvement would allow us to quietly remove the env var once our performance goals are reached since the users just want pulumi to be faster and we could hide the implementation details since it'd reduce our flexibility. i.e. |
The PR implements https://www.pulumi.com/docs/intro/concepts/state/#checkpoints seems to be the official docs that give some vocabulary to what Pulumi does here ("record a checkpoint"). Perhaps:
This opens up adding some more options down the road.
|
I like the
I think they better communicate that we will stop doing something we should otherwise be doing. We should definitely gate these behind
|
Reopening since we would like to better name the environment variable. |
This shipped as an env-var based flag:
Looking forward to feedback. |
Hello!
Issue details
Consider adding a --save-final-state-only flag to trade safety for speed. This flag would be relevant for situations where:
the state is very large (many resources, large resources)
Pulumi CLI crashes or disconnects that might lead to inconsistencies between the state of the cloud and the state checkpoint internally tracked by Pulumi in the statefile (or service) are not a serious concern - either unlikely or easy to recover from
The flag would ask Pulumi to only write the state at the end of a deployment (pulumi up, etc). The default behavior for Pulumi is to write the state immediately after it is making changes. A stack update that creates N resources is currently generating O(N) state writes, and it can slow down large deployments.
Currently
pulumi up
does this (example using the httpstate backend):The new behavior of
pulumi up --save-final-state-only
would be using only one PATCH at the end:The treadeoff is that in case of a catastrophic failure of the
pulumi
process the intermediate state changes it has performed will not be written to the state backend.The flag would universally apply to the httpstate and filestate backends.
Alternatives and related tickets
Naming possibilities
Affected area/feature
area/backends
The text was updated successfully, but these errors were encountered: