Terraform 1.1.0 will include a new command, terraform add , which can be used to generate resource configuration - either a blank template which you can fill in, or configuration generated from an existing resource in state.
This function is available in today’s v1.1.0-alpha20210630 release. The add command documentation is not yet published on terraform.io, but you can view it in Github.
The usual caveats apply: this is an alpha release, not supported for production use. Instead, please try out the release in isolated test environments.
We’d love to hear any feedback on this function! Feel free to leave any thoughts and ideas for terraform add here. If you come across any bugs, please open a Github issue .
We’re really eager to see this! We see this as unlocking a bunch of very cool development workflows for us
I’m sure there’s a laundry list of additional functionality y’all are thinking about adding, but I have some specific ideas.
It’d be very cool to have -out replace the existing resource in the destination file, if the resource already exists in the state and unambiguously resolves to a specific resource (hard to see how that intersects with modules and for_each, though). One of the main use-cases here is to have a CI mechanism that opens pull requests with the updated Terraform config after we detect changes to the true resource state.
It might be interesting to have scriptable hooks that can assist in augmenting properties by deriving them from other resources in the file, though perhaps an alternative solution would include some easily scriptable CLI that can alter Terraform configuration after running terraform apply.
Interesting, so this should eventually simplify terraforming existing infrastructure into configuration. I think that there should be couple of SDK methods added for this to work properly - some resources may want blobs of text as HEREDOC, others may want them in files. Adding linking of resources through IDs is relatively straightforward. There’s also a need to “discover what resources there are”. We’d need some sort of “terraform generate” command for that.
@skeggse having CI to detect and add configuration is a bit slow, because all resources have to be listed. Also imagine states with 10k+ resources. It’s also difficult for CI to know where to place the autogenerated config It could be figured out for the scope of single provider, but globally it’s not that easy.
@mildwonkey I’ve noticed that in the latest beta release note of v1.1.0, the terraform add is removed. May I know why is it removed from the release plan?
We released terraform add this past June, and soon realized we weren’t entirely sure about the design and implementation. We decided to remove the command in the 1.1 Alpha ( here’s the PR ), before too many users could build core workflows around the feature.
With that, I’d be happy to chat about concerns and get some use-cases for generating resource configuration. We’re also working on better messaging about expectations when it comes to our experiments, as we’ve realized people are building core workflows around them and we ought to be more clear about our plans.
@mildwonkey Oh, sorry to hear about that. Thank you for your past works and best wishes for your next advanture!
@korinne, I can understand your concern. While I still like to see some way that developers can convert stuff from terraform state to a terraform configuration. IIRC, projects like “terraformer” has a lot of code to handle this conversion. Things become worse since some version of Terraform v0.15, all the state related packages are moved into “internal” package. The terraform add -from-state actually changed this situation a bit, with the support in the terraform-exec, developers can now easily do that conversion.
Additionally, I’ve already have a project (recently moved to the Azure org) aztfy that depends on the terraform add, I really hope we can bring that command to the v1.1 release (, also bring the terraform add back to the terraform-exec).
It could be figured out for the scope of single provider, but globally it’s not that easy.