search

hashicorp / terraform

Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.
https://www.terraform.io
Other
43.15k stars 9.58k forks source link

Allow providers to plan additional imports #33442

Open Klaas- opened 1 year ago

Klaas- commented 1 year ago

Terraform Version

v1.5.1

Use Cases

https://github.com/hashicorp/terraform-provider-azurerm/issues/8162

Currently the Azure API creates certain dependent resources on it's own using the VM creation API call. This is something terraform currently does not understand. By enhancing plannable imports we could put the os disk that gets created during the VM creation into terraform control and stop configuration drift by setting tags/size/whatever properly via tf.

Attempted Solutions

The workaround MS came up with is by using the azure api directly to modify the os disk, see https://github.com/hashicorp/terraform-provider-azurerm/issues/8162#issuecomment-1612611058

Proposal

Change plannable imports so that you can use them a) not just in the root module, but also within sub modules b) have it pick up on resources created during the terraform apply, they do not exist prior to running apply yet.

References

https://github.com/hashicorp/terraform-provider-azurerm/issues/8162

jbardin commented 1 year ago

Hi @Klaas-,

Thanks for documenting this use case! One aspect of Terraform's operation which we cannot break here is that Terraform will only ever apply the operations which are planned, so this would all need to be accomplished within the plan, however I don't think that alone would preclude this idea. The providers have the same knowledge during the plan about what is going to be applied as they do during apply, and therefore would be able to account for these implicit resource types at that time as well.

Importing into sub-modules however is a different affair. Modules are treated as read-only by Terraform (except in some exceptions which are maintained for backward compatibility), so imports into submodules must always be targeting existing configuration. The concept of generating configuration within a sub-module's namespace is an idea which will be addressed separately. Currently the solution would be to generate the configuration in the root module, then the user can refactor the configuration via whatever means necessary.

jpbuecken commented 1 year ago

Hello, I just want to bring to your attention that the VMware Cloud Director has a very similar use case.

The vm resource creates the boot disk, but similar to azure, it is a dependent resource that you cannot manage with VM api calls. So the developer did not add support to the vm resource yet.

One solution is to import the boot disk in a vcd_vm_internal_disk resource. Then you can manage storage type or size.

You can find discussions here: https://github.com/vmware/terraform-provider-vcd/issues/519