canonical / solutions-engineering-automation

Repo for automating tasks for Solutions Engineering Team.
1 stars 4 forks source link

[Discuss] Do we want to store terraform state in remote backend? #25

Open jneo8 opened 4 months ago

jneo8 commented 4 months ago

More refactor topics:

samuelallan72 commented 2 months ago

My thoughts on the points here:

Do we want to store terraform state in remote backend?

While the stateless importing is still working for us, I say we don't change anything. Adding remote backend adds complexity, so I reckon we carry on as-is until we have a real need for it.

Put every repository in tf's variable instead using matrix to run parallel.

I do like this. Although our current setup using matrix and separate tfvars is working ok mostly. I think the main target of refactoring here is probably going to be to make it one tfvars per target repository (currently we need one per (repo, branch) which duplicates data).

With using tf state, maybe we don't have to compare the file content in main.tf. No sure if we will have issue if target files are not compare with the state we have, someone change directly on the repository.

For these, I reckon we need to stop using terraform for the files and PRs altogether; it doesn't fit terraform's model properly and it's awkward. See https://github.com/canonical/solutions-engineering-automation/issues/52 for more thoughts on it.