Hacker News Reader

Comment by jrochkind1 | Hacker News Reader

> On terraform it's different, because of the tfstate. All the deployed elements are stored in the tfstate, re-running terraform won't update resources that are supposed to be in a specific state but are not.

Huh, is that true?

I'm just getting started with terraform but I assumed that was the idea of terraform (where it didn't happen would be a bug), and I think I had seen it happening for the few basic resources I have started out with (S3, cloudfront).

If the state doesn't match the actual configuration of S3, terraform notices, and the plan is to make it so. No? Am I confused and it hasn't been doing this?

Or is this is inconsistent, true of some resources and not of others? That seems surprising. What's the idea?

View on HN

If Terraform was used for the deployment of the infrastructure, then state IS the actual configuration of the system.

All that a plan does is evaluate what is going to change in the current Terraform state by performing a dry-run of the Terraform code that you have supplied.

If you would actually like to make changes to the Terraform state based on what the Terraform code evaluated then you run a Terraform apply - which will, for the resources deployed via Terraform, update the configurations themselves and update the Terraform state by using the Terraform code as the instruction set.

You can actually see this in action with plan and apply as the output will show you +,-, and ~ where ~ is settings that are going to change but are not new configurations or configuration to be removed.

Edit: Learned from some other comments that Terraform has a 'refresh' command that will take deploy+n time configurations done outside of Terraform and sync those configurations with the state. This might be what you ideally are looking for after deployments?

Right. I guess I'm asking about what happens if state changed outside of terraform.

I thought I had seen terraform correcting it (to match what terraform thinks it should be) in some cases.

OP seems to suggest that in some cases it does and in other cases it doens't. I am surprised if that is inconsistent and unpredictable, and would have expected terraform to (modulo bugs) either always or never do that. And am wondering what terraform's intent is with that.

Made an edit to my original comment but it may help to be here also.

'terraform refresh' may be what you are looking for. This will update the state to match current configurations that may have been done outside of Terraform.

From https://www.terraform.io/docs/cli/commands/refresh.html :

> You shouldn't typically need to use this command, because Terraform automatically performs the same refreshing actions as a part of creating a plan in both the terraform plan and terraform apply commands.

I'm talking about fixing the external actual configuration that has diverged, to match what terraform config wants it to be.

However, snom380 says this is what terraform is intended to do, and does with properly implemented providers, which makes sense to me.

I'm not sure if you are talking about the same things. We -- me, snom380, and the original quote I made from OP -- are talking about what happens when external actually existing live resources have diverged from terraform's state. I understand what you said that under a "perfect" situation, this would not happen. But it does sometimes for various reasons, what the original quote from OP is talking about and what I'm talking about is what happens when it does. I think maybe you are talking about something else.

It's not true, and what you describe is correct.

I can only assume that the author has used some provider that hasn't implemented this properly (helm, I believe, is one example), or that they've run into one of the cases where terraform treats configuration/attachments to a resource as a separate resource (e.g. IAM role vs attached/inline IAM policies).

Reply on news.ycombinator.com