5 ms·
> 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
by snom380 5y ago
> 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.
This is incorrect, and makes me wonder how the author has used terraform. Terraform will certainly detect differences between managed and current state for the resources it manages whenever you do a plan/apply.
The major challenge is that terraform _can only reconcile resources or configuration values it knows about_, and that depends very much on how a particular cloud vendor or terraform provider has modelled resources. I believe the Helm provider is one example where it (at least in the past) haven't had a good way to reconcile state.
- deleted 5y ago[deleted]
- dead10ck 5y agoThis stuck out to me too. Terraform absolutely does check the current reality of the state and applies changes to do what the HCL tells is to. They are either using terraform in a really weird way, or this article was written by someone that doesn't actually run terraform themselves.
- jrochkind1 5y agoPhew! I thought I was misunderstanding terraform when I saw that. Perhaps they are working with certain poorly implemented or buggy providers, and not realizing those providers were doing something different than terraform's properly working behavior that most providers implemented. Bugs happen, but the first step is agreeing on intended behavior so we know what's a bug!
- shadycuz 5y agoI also agree, but I don't have experience with the providers he is using. When working with AWS it will always reapply the terraform configuration. A great use of this is for account hardening. You can run it daily to make sure it's configured correctly.
- OJFord 5y agoIt would be even better if you could somehow tell it it should have control over the entire account, so that anything (entire resources I mean, not just changed properties) created outside terraform would be destroyed. In terms of API use though I suppose that'd be quite expensive to plan - listing every possible AWS resource (in every region!) for example.
- joombaga 5y agoYou'd have to go per-region first to avoid a major redesign on the provider (the API is also per-region). I can see something like a `controlled_resource_types` list attribute on the provider that you could set to e.g. `[aws_instance]` to inform the provider it needs to compare the list of resources of the specified type to the state.
- OJFord 5y agoTrue. That'd be fine though, if you wanted to be really thorough you could just specify a provider for every region and only actually 'use' the ones you wanted, the others just serving as a dummy to enforce no resources.
- sciurus 5y agoRelatedly, I'm pretty sure the earlier statement > For some resources like RDS or EKS, it won't check if the resource already exists or not. So if it's missing, nothing is going to happen as it's marked are deployed in the tfstate file is also wrong.
- joombaga 5y agoIt is, at least for most RDS and EKS resources (RDS cluster, cluster instance, parameter group, EKS cluster)
- robertlagrant 5y agoThe author also seems to think DSL means "descriptive languages" and that Helm "even" supports kubernetes, when in fact it's only for that technology.
- forty 5y agoThe stage when terraform read the reality to compare it to the current state is called "refresh". It can optionally be skipped.
- raffraffraff 5y agoThere's also brokenness around terraform for_each and providers. If you have a module that creates a Kubernetes cluster and then applies a helm chart to it, you can't convert it to one that takes a bunch of cluster definitions that it iterates over using for_each. Basically, there is no way to do this in a date driven way. Sucks.