nabuskey
commented
3 months ago Some reasons I did not go with other open source solutions in the initial example:
- I did not like double reconciliation process by Flux controller when deployed with ArgoCD.
- I did not want to use Crossplane TF provider because I did not want to confine ourselves to Crossplane.
- Resource requirements. I didn't like the idle resource usage required by controllers.
- Ease of visualization in Argo Workflows.
- DoEKS has its own install and cleanup scripts.
I think the way it was implemented was a mistake. We should go with an existing solution instead.
From my testing, the flux TF controller or tofu controller works well. I just did not like the way reconciliations are handled with ArgoCD. Flamingo was an attempt at resolving this but I don't think we should use it.
I think my second point above is still relevant . If we want to integrate with TF, we should try to find a solution that does that specifically.
We also need to figure out how to handle scripts that wrap TF.
csantanapr
nimakaviani
elamaran11
Currently the terraform blueprints are deploy using argo-workflows, we want to move away from this approach and instead use some type TF Controller, that will allow user to edit their terraform in git, and the controller be able to re-apply, and maybe destroy the terraform plan
Here are some terraform k8s controller projects to look into:
We need to pick one to do implement as a references architecture, the other would be homework to the user or can be contributed as examples.
cc @nimakaviani @elamaran11 @nabuskey