4 ms·
I think state management is unavoidable for something like Pulumi. If it had to query AWS's API for all of your thousands of resources every time you deployed,
by johnsoft 5y ago
I think state management is unavoidable for something like Pulumi. If it had to query AWS's API for all of your thousands of resources every time you deployed, deploys would be unbearably slow. So it just assumes your hundreds of DNS records from yesterday are all still there, instead of querying AWS for all of them every deploy. The state file is how that happens.
If you want, you can run pulumi with the --refresh flag and you can see just how much slower it is.
- throwaway823882 5y agoThat's more of a cache than a state file. It's great that it supports a cache (other CM tools do too) but you obviously need to refresh it before you deploy changes, or you don't know if your changes will break. Even if you're not changing those specific records, some other change you're trying to make may depend on the latest DNS record values, and so you'd want the latest version of them before you deploy. Ansible does not need a state file to manage AWS R53 records, but it does support a cache. (This is not an endorsement of the tire-fire that is Ansible.) Terraform's .plan file is like a cache before you apply changes. Since it's synced up to the state file too, it will fail to apply if the state has changed, so it's useful to "safely" apply only changes that seem like they might work. The problem is the state file acts like a giant boat anchor tied to the HCL code the rest of the time.