3 ms·

The concept I struggle with is "the desired state, the last known state and the current state" Why do you need to know the last known state. You have the desi

by ta1243 3y ago

The concept I struggle with is "the desired state, the last known state and the current state" Why do you need to know the last known state. You have the desired state and the current state, you run your code and you reconcile the current state to the desired state I get why this is impossible/expensive to get the current state with AWS, which doesn't expose a simple "show state" API, but managing a state store is extra work and thus extra fragility. However ideally I'd like to list credentials and providers to manage, then say "manage all resources with some form of tag "managedByTerraform=12345" (this could even be in the resource name -- for my fortigate management my scripts manage firewall rules, addresses, etc which start with AUTO_, and ignore the other objects) It would then run, generate a lock resource, find the current state, compare with desired state, create/delete elements to reconcile actuality with desire, implement, free the lock Then all I need to do is have that human readable file and I can get back to where I am If I lose the state, or it gets corrupt, I'm in for a world of hurt with terraform.

oneplane 3y ago
What you propose is computationally rather expensive, and on an API level really hard to implement uniformly. And thus the state was born. Trying to do it without state has been tried plenty of times, and it's bad. (Chef, SaltStack, Ansible, CFengine, Puppet to name a few) It only works somewhat okay if you're simply writing to a single managed unit, i.e. a file. You know what all the contents of the file have to be, so you can replace it wholesale. This does not work for a graph of resources that interact with each other. Separately, this also doesn't work with a shared responsibility model and doesn't work with deleted code. Terraform has a state because that is required to solve the problem in a reasonable manner. It doesn't have state just because it was thought to be a fun exercise ;-) If the problem being solved is not _your_ problem, it is highly likely that using terraform at all is also not going to help you. > If I lose the state, or it gets corrupt, I'm in for a world of hurt with terraform. And that's why you secure and version your state. I.e. using S3 and versioning and a restrictive policy.

by ta1243 3y ago

oneplane 3y ago

What you propose is computationally rather expensive, and on an API level really hard to implement uniformly. And thus the state was born. Trying to do it without state has been tried plenty of times, and it's bad. (Chef, SaltStack, Ansible, CFengine, Puppet to name a few) It only works somewhat okay if you're simply writing to a single managed unit, i.e. a file. You know what all the contents of the file have to be, so you can replace it wholesale. This does not work for a graph of resources that interact with each other. Separately, this also doesn't work with a shared responsibility model and doesn't work with deleted code. Terraform has a state because that is required to solve the problem in a reasonable manner. It doesn't have state just because it was thought to be a fun exercise ;-) If the problem being solved is not _your_ problem, it is highly likely that using terraform at all is also not going to help you. > If I lose the state, or it gets corrupt, I'm in for a world of hurt with terraform. And that's why you secure and version your state. I.e. using S3 and versioning and a restrictive policy.