Now more will be using a combination of OpenTofu and Terraform, and there will probably be some tacit endorsement of OpenTofu by Hashicorp folks in their communication with those who are using both. Good to see!
You can just switch from `count = 1` to `enabled = true` (or vice-versa, works back-and-forth) for a resource and tofu will automatically move it next time you apply.
I’m not sure I understand. You refer to the conditional resource fields normally - without list indices. You just have to make sure the object isn’t null.
There’s some samples in the docs[0] on safe access patterns!
And you don't get the annoying array form for the resulting resource with the `enabled` syntax, right?
EDIT: Oh just realized the sibling asked the same, but the doc doesn't state that clearly, although it seems to me that the doc implies that yeah, it doesn't use the array form anymore.
Worth switching to Opentofu only for this, then! I fuckin hate the count pattern for conditional present/not present that leads to an array of size == 1.
Speaking of IAC- I have an existing GCP project with some basic infra (service accounts, cloud run jobs, cloud build scripts, and databases) what is the best tool to _import_ all of this into IAC. The only real tool I’ve found is terraformer. I have no dog in the race regarding tooling e.g if my output is Pulumi, terraform, or just straight YAML. I’m just looking to “codify” it.
You can check the docs for the GCP provider to see if the resources you want to manage are "importable" into the Terraform state file; they usually are and you'll see a section at the bottom of each resources documentation page showing you how to do this. e.g. https://registry.terraform.io/providers/hashicorp/google/lat...
Your process will be -
1. Write TF configuration approximating what you think is deployed
2. Import all your resources into the state file
3. Run a `terraform plan ...` to show what Terraform wants to change about your resources (including creating any you missed or changing/recreating any your config doesn't match)
4. Correct your TF configuration to reflect the differences from 3.
5. Goto 3, repeat until you get a "No changes" plan or the you actually want TF to correct some things (add tags, for example)
6. run `terraform apply`
and optionally...
7. set up your CI/automation to run `terraform plan` regularly and report the "drift" via some means - stuff that has been changed about your resources outside of Terraform management.
I put a lot of stock in this last step, because small, incremental change is the cornerstone of platform management. If you want to make a change and come to find there's a huge amount of other stuff you have to correct as well, your change isn't small any more.