We are migrating to Terraform 12 from Terraform 11, so we have a number of deployments still using Terraform 11, we have an in-house module which we use to lookup information (ip lists, names of things etc) that is still coded as "terraform 11" so we could avoid having to maintain two modules, one for TF 11 and one for TF 12.
The module works fine in a plan/apply in TF12, however it does not work on an import. This unfortunately is something we just realized.
here is the TF12 error on import ..
on .terraform\modules\azure_lookups\main.tf line 1180, in locals:
1180: SubscriptionName = "${lookup(local.SubscriptionNameUsingFullName , lower(replace(var.subscription_name, var.regex_replace_chars, "")))}"
|----------------
| local.SubscriptionNameUsingFullName is object with 16 attributes
Invalid value for "inputMap" parameter: the given object has no attribute "".
Terraform v0.12.7
+ provider.azurerm v1.33.1
The module declaration (which works)
module "azure_lookups" {
source = "https://xxxx.xx.xx.xx:443/artifactory/xxxx-maven-releases/com/xxxx/xxxx/terraform/azure_lookups-module/0.0.0/azure_lookups-module-0.0.0.zip"
subscription_name = "xxx-xx-xx-xx"
azure_region = "eastus2"
}
The part of the module which has the errror (works using terraform 0.11.14 import)
SubscriptionName = "${lookup(local.SubscriptionNameUsingFullName , lower(replace(var.subscription_name, var.regex_replace_chars, "")))}"
The import was successful (it used to work in Terraform 11)
The import fails
terraform init
terraform import azurerm_resource_group.fzcu-trafrm-li-npd-rgp-05 /subscriptions/xxxxx-xxxx-xxx-xxx-xxx/resourceGroups/fzcu-trafrm-li-npd-rgp-05
I would hazard a guess that the lookup itself "is not working", if I set the default value on the lookup it will no longer error out... however the lookup itself doesn't work (it fails to lookup the value and so uses the default).
I have identified the root cause of this issue. In at least MY case, when using terraform import with a var file and modules, if the module variable has a default value... it uses that default value and not the value in the module resource.
I removed the default value (from the module variable) and now the import works and the module looks to be generating output etc.
Should I re-open this or something on the actual issue, which seems to be that when using terraform import with a module (using a var file might also factor in) that has a default value the default value is used instead of the value provided in the module resource declaration.
Debug output from terraform import with module when it has default value set, and one where the module doesn't have the default value set.
https://gist.github.com/runecalico/1e53eb83ec7ec6bf011623c8b5e7933e
This behaviour still exists in 0.12.9.
If I try to import a resource created by a module (for example an azurerm_app_service_plan), the import will fail because the input variables to the module will not be passed to the module if the module has default values for that input variable. Commenting out the defaults (in the child module) allows the values to be passed to the module and the import succeeds.
Can confirm this exists in 0.12.16.
This happens when a child module uses a variable that has defined a default value.
When we try to pass in a variable to overwrite that value using --var-files ./values.tfvars in my case, the value will not be overridden. Rather the default value will be used.
Reproduced the same issue using 0.12.17. Not able to override default values when importing resources.
I've also encountered this on several occasions.
Often the resources causing the refresh trouble are unrelated to the resource being imported. One workaround that I've found effective in those situations is to just hide the TF definitions for the resources causing trouble (e.g. rename the file .tf -> .tf.backup
), do the import, and then reintroduce them.
Not yet fixed in terraform v0.12.24
+1 seeing this issue in v0.12.24
Also in 0.12.25
The issue exists in v0.12.26 and I've verified @jbergknoff-rival's work around got the import to work.
Most helpful comment
+1 seeing this issue in v0.12.24