The difference between Terraform and Pulumi strikes us again in multiple flows When we create certain objects in Google Cloud such as Load Balancers and Service Attachments - these resources are created via Pulumi but then sometimes get modified outside of Pulumi. When running

pulumi up

after these resources have been modified + some changes were made in Pulumi - the state file contains old

fingerprint

value, which is submitted with the extra change, since the

fingerprint

is stale - we get the following error:

Invalid fingerprint., conditionNotMet

Important - This does not happen with Terraform (

terraform apply

) Why? Because

terraform apply

runs a state refresh on a changed resource just before actually computing the diff (again) - so the fingerprint is updated as well. One would argue “no problem, just always run

pulumi up --refresh

or `pulumi up --refresh --target …`” This is not a good answer, running a refresh with a specific target is a manual flow which we want to avoid - we want smooth sailing running the same

pulumi up

command always. Also using

pulumi up --refresh

always behaves differently than Terraform - since it refreshes the entire stack before running the update (as far as I remember) so this makes stacks with many resources compute unnecessary updates + call refresh APIs on the resources + sometimes fail on resources that are currently unavailable to the caller or w/e. So Pulumi’s refresh options are too “crude”, there is no way to specify the terraform behavior: Compute Diffs -> Find changed resources (code <-> state) -> Refresh only those resources with actual data (don’t commit the refreshed data, in case of cancel) -> Compute Diff -> Show Diff -> Update resources (and apply the refresh) Obviously the terraform google provider was written with the default terraform behavior in mind, and that’s why terraform users simply don’t encounter such errors (unless the run with

terraform -refresh=false apply

flag). So its also not possible to upstream changes to the terraform provider that make sense only for Pulumi users. Please can anyone advise on any solution to such problems / roadmap in Pulumi to make such super popular and critical providers “just-work” with Pulumi. I found this long standing issue from 2018 by @white-balloon-205 (prev CTO of Pulumi) - but no updates since: https://github.com/pulumi/pulumi/issues/2247 Should I submit this entire message as an issue on the GCP provider?

> Because

terraform apply

runs a state refresh on a changed resource just before actually computing the diff (again) Are you sure about that? The documented behavior is that when you run

terraform apply

without a plan file, it runs

terraform plan

and then prompts you whether you want to accept the plan. And for

terraform plan

, the documentation says: > By default, Terraform performs the following operations when it creates a plan: > • Reads the current state of any already-existing remote objects to make sure that the Terraform state is up-to-date. > • Compares the current configuration to the prior state and noting any differences. > • Proposes a set of change actions that should, if applied, make the remote objects match the configuration. As far as I'm aware, this is equivalent to what Pulumi does.

What you’re trying to say is that

terraform apply

IS equivalent to

pulumi up --refresh

if I understand correctly. (at least for the fact that it refreshes ALL resources indiscriminately to changes in the code) I need to recheck this since I saw differently when writing tests in the magic-modules repo.

> What you’re trying to say is that

terraform apply

IS equivalent to

pulumi up --refresh

if I understand correctly. Yes, that's my understanding and my current mental model. (I would also find a pattern where resources are refreshed only when there is a difference between the coded configuration and the stored state quite strange, this seems like an arbitrary and not-very-useful criterion when the goal is to discover drift.) I'm using both Terraform and Pulumi frequently, with and without plans and refreshing, and I don't think there is a difference when it comes to the general approach the tools take.