Would say that half of the point with Terraform is that you have a canonical expected view of the infrastructure and the state as a log to assert that in each environment. It forces you to do all changes in a code first manner. Terraform only solves the provisioning part and is easier to work with than Ansible. One need something like Ansible too for configuration though.
Terraform should have remained stateless
161–170 of 329 posts
Re: Terraform should have remained stateless
#162The article mentions using tags in lieu of state. What are tags, if not state?
Yep and the configs are state too. These tools (Chef, Puppet, Ansible, TF, etc) are state replication engines; they replicate the state described in the config into other systems.
Re: Terraform should have remained stateless
#163Earlier quoted context omitted.
The whole idea of the article is that “previous state” is something that can be derived from tags / metadata in the provider’s resources, rather than a standalone file. In other words, this metadata then is the state. Could you give an example of a situation / transition that cannot be captured correctly by managing the state using these types of tags?
This is the fundamental misconception of the article as far as I understand it. Cloud providers do not provide enough metadata to enable that mapping across all resources.
That cloud providers provide such muddy/inadequate APIs that it is impossible to view the state they are in is a very bold claim to make.
Do you have an example to back this up?
Re: Terraform should have remained stateless
#164I respectfully disagree. If TF was stateless, you'd have to manage situations by hand that involve changing the idempotency key, such as the name of a VM. You'd also have to manage situations by hand where a resource is removed from the config. The whole point of TF is that it has state and doesn't require workarounds for these scenarios. Yes, you have to maintain state, but the state problems usually come from buggy…
Why would renaming be impossible to solve by a stateless terraform?
In a cloud setup with 3 VMs, and you rename 1 VM from A to B:
Measured cloud setup would have VMs A + X + Y
New cloud setup would specify VMs B + X + Y
You can easily identity X and Y as their names go unchanged, A and B would have similar config/metadata, instead of assuming A would be added and B would be removed you can ask the user if a rename happened.
This is not a new problem to solve by the way, this is how database migration tools handle column renames.
Re: Terraform should have remained stateless
#165> Ansible, Puppet, etc. don’t have intermediate stores of the hosts’ configuration, but then again they are used for different things. Ansible, Chef, Puppet and co existed long before Terraform. If the stateless way would work better, these tools take over the cloud infrastructure space. But they didn't. To me it seems like a good sign that the their approaches didn't fit to infra. Additionally, one of the biggest te…
Ansible and Puppet are for infrastructure automation across multiple VMs.
Terraform is a way to declare cloud (native) infrastructure as code.
Ansible and Puppet are not used anymore because of the shift to cloud native, not because they are stateless.
Re: Terraform should have remained stateless
#166The article misses a key bit of information TF needs when making a plan: 4. The previous Terraform configuration This is effectively stored by state. We need this because if a resource is removed from the new config then Terraform needs to be able to delete the existing resource from the world. If we don’t have the state then Terraform must either: 1. Not delete it from the world 2. Or risk deleting something not man…
The whole idea of the article is that “previous state” is something that can be derived from tags / metadata in the provider’s resources, rather than a standalone file. In other words, this metadata then is the state. Could you give an example of a situation / transition that cannot be captured correctly by managing the state using these types of tags?
So the position is Terraform should have state, but rather than keep it in one place such as an S3 object, it should be spread across the metadata of many resources?
Some issues with that:
- Fetching the whole state would be hugely impractical due to the number of API calls
- The risk of losing state information by a resource being deleted outside of Terraform is greater
- Again, not all resources have metadata that could be used to store state
Re: Terraform should have remained stateless
#167Here’s an idea: a new cloud provider that can only be interacted with in a declarative way. It forces you to work like Terraform.
Re: Terraform should have remained stateless
#168Earlier quoted context omitted.
This is the fundamental misconception of the article as far as I understand it. Cloud providers do not provide enough metadata to enable that mapping across all resources.
That cloud providers provide such muddy/inadequate APIs that it is impossible to view the state they are in is a very bold claim to make. Do you have an example to back this up?
No DNS provider I've ever used has a way to store metadata alongside a DNS record (like an individual A record)
Re: Terraform should have remained stateless
#169Earlier quoted context omitted.
The whole idea of the article is that “previous state” is something that can be derived from tags / metadata in the provider’s resources, rather than a standalone file. In other words, this metadata then is the state. Could you give an example of a situation / transition that cannot be captured correctly by managing the state using these types of tags?
I agree that state can be removed in Terraform. But I do not believe leveraging tags and/or metadata is the right approach - configuration for these resources could potentially be large (e.g. GKE resources) and most providers will have a size constraint on their metadata and tag values. Creating a metadata/tag key for each configuration key would also get messy, but solves the value size problem. Why wouldn’t it be p…
How would TF work without state and without tags?
Let's say your TF config declares a database Foo. Your AWS account has databases Foo and Bar. How does TF know whether it's responsible for database Bar and whether to delete it?
Re: Terraform should have remained stateless
#170Earlier quoted context omitted.
That cloud providers provide such muddy/inadequate APIs that it is impossible to view the state they are in is a very bold claim to make. Do you have an example to back this up?
No DNS provider I've ever used has a way to store metadata alongside a DNS record (like an individual A record)
I was just about to give the same example. I’m more familiar with GCP’s DNS, but I don’t see a place for structured metadata in Route 53 either. https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...