Terraform should have remained stateless

One of the fundamental issues that I’ve encountered in all of the puppet managed environments is that people would remove resources from the configuration without first explicitly setting them to “absent”, effectively leaving them in an unmanaged state of the previously management configuration. If that state differs from the default, a new machine would end up with a different configuration, potentially breaking things.

Not suggesting it "should", I was just pointing out that it's not a complete drift detection tool.

You could work in some way without a state but actually the state is a feature which helps you.

Imagine you go down the ansible route and you write idempotent ansible code than you could argue: “See. I don’t need state. My code is idempotent. I just use this playbook to apply”

Now think of deleting resources.

You could have a delete playbook maybe. Then how would choose whether to create or delete stuff? Maybe a colleague gives you a ticket: “please delete”

Now there are various scenarios:

You do your thing (on your laptop) and tell everybody else in your team to not run the CreatePlaybook as you have to run the DeletePlaybook first for this one machine. Afterwards you delete the actual machine/resources from your ansible repository and tell the team: “please use the newest main branch”.

So: Here is your equivalent to terraform state, the coordination effort on your side since you are the only person who currently “knows” what’s going on with deletion/applying.

So your next idea is: “no problem, I make a Pipelines which runs the playbook on your behalf”. And the pipeline will update maybe the Git repo accordingly in some way - after the run (since ansible needs to know in the run, what to delete).

Everybody can see the pipeline . The pipeline will ensure you sequentially apply the playbooks to coordinate with your colleagues.

Next problem: how does the pipeline know which playbook and resources to run on?

You create a selection box for your hosts and for the playbook yaml to trigger the pipeline.

=> there is your state. Your ticket information are transferred to your manual labor to fill in the correct items in your selection box. To reestablish want went on you now have to look in the ansible code and the pipeline Paramus and pipeline logs.

More examples are: you only want to update some stuff with your ansible playbook. Therefore you might introduce tags on the resources and the playbook knows how to handle those tags. The extreme case might be:

TTag:state:present, tag:state:absent.

Then you can run a single playbook which can call the deletion and installation playbook for you and everybody is happy that you have everything visible in Git.

Problem here: your 2 step process to decommission things from git. First a commit which sets state:absent. Then run the pipeline and then another git commit to delete the code.

So what I am saying is: You can do all of this with ansible for sure. But you will have state somewhere:

In a Ticket, a Pipeline log, in git, in a wiki

I am not saying absible should not be used. It makes sense to configure things. (I personally would wrap a terraform hull around my absinble code and call it, just to have terraform handle the locking for my playbooks)

But just watch out for the hidden state in your workflows and better make it explicit. This is why people love GitOps for traceability.

You can all do this by hand and document your process in a Wiki for your colleagues so that they known what the “tag:state:absent” means for them. Or you can rely on somebody who has done this for you already and maintains documentation and what not.

Terraform having state is a trade-off:

Pros:

- it can manage resources where not all information can be queried

- reading state is almost always significantly faster

- it can identify deleted resources

Cons:

- state can go out of sync

- every resource type has to implement state well while tracking changing features, so it’s fragile

- fixing broken state can be a PITA

Without making these trade-offs, terraform would only be able to support a smaller subset of the providers it currently does and perform poorly.

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?