Could someone help me to figure out whether terraform updates the state file after receiving all responses from provider or terraform updates the state file little by little as long as it receives response from the provider.
There are two cases, could you please tell me which is right.
apply 5 resources, terraform sends 5 apply requests to provider, and after all 5 responses are received, the terraform updates the state file.
apply 5 resources, terraform sends 5 apply requests to provider, as long as one response received, terraform updates the state file.
How the state file is persisted is an implementation detail, depends on how the state is being stored, and the details are subject to change in the future. The in-memory state representation is of course updated immediately as each resource instance response is handled, a local state file is also updated after each resource is written, but what that means exactly depends mostly on filesystem buffering, and a remote state is persisted at least once upon completion of the run.
Hi @jbardin ,
Does “a remote state is persisted at least once upon completion of the run” mean that the remote state file will never be updated if terraform process is hard killed during the run, caused by computer power failure. At that case, how do I know which resources I have created?
A more extreme case. If the resource ID is randomly generated by random_id, how do I know which resources I have created if the remote state has not been updated due to a computer power failure?
Thanks a lot.
If the computer executing Terraform has failed in the middle of a run, you’re stuck manually examining what resources exist and deleting things that don’t match up with Terraform state.
If Terraform is prevented from exiting in a normal way then indeed the latest state snapshot may be incomplete, and in the extreme case may not track anything at all.
If Terraform is terminated before it gets an opportunity to commit the final state snapshot for any reason then you will need to reconcile the state with the real infrastructure manually, for example using terraform import.
A typical way to mitigate this risk is to run Terraform in automation when working with important infrastructure, and set up that automation to capture artifacts that you can use to recover information in the event of failure. For example, if your automation system saves the output from creating a plan then you will be able to see in the plan which objects Terraform was intending to create, even if the apply phase is aborted. If your automation system captures the progress output from the apply phase and is able to flush that information to a durable data store before the system fails then you will be able to see information about what Terraform has definitely already created.