Terraform v0.11.7
+ provider.azurerm v1.5.0
data "terraform_remote_state" "root" {
backend = "local"
config {
path = "../statefiles/abc.terraform.tfstate"
}
}
resource "azurerm_resource_group" "rg" {
name = "${format("%s-Bastion", data.terraform_remote_state.root.resource_prefix)}"
location = "${data.terraform_remote_state.root.location}"
tags = "${data.terraform_remote_state.root.common_tags}"
}
Additionally referenced terraform file contains:
terraform {
backend "local" {
path = "statefiles/abc.terraform.tfstate"
}
}
variable "common_tags" {
type = "map"
}
output "common_tags" {
value = "${var.common_tags}"
}
The value for the common tags would be:
common_tags = {
Scope.Environment = "test"
}
2018/05/18 16:30:54 [ERROR] root: eval: *terraform.EvalValidateResource, err: Warnings: []. Errors: [tags (Scope): '' expected type 'string', got unconvertible type 'map[string]interface {}']
2018/05/18 16:30:54 [ERROR] root: eval: *terraform.EvalSequence, err: Warnings: []. Errors: [tags (Scope): '' expected type 'string', got unconvertible type 'map[string]interface {}']
2018/05/18 16:30:54 [ERROR] root.nsg: eval: *terraform.EvalValidateResource, err: Warnings: []. Errors: [tags (Scope): '' expected type 'string', got unconvertible type 'map[string]interface {}']
2018/05/18 16:30:54 [ERROR] root.nsg: eval: *terraform.EvalSequence, err: Warnings: []. Errors: [tags (Scope): '' expected type 'string', got unconvertible type 'map[string]interface {}']
2018/05/18 16:30:54 [DEBUG] plugin: waiting for all plugin processes to complete...
Error: Error running plan: 2 error(s) occurred:
* azurerm_resource_group.rg: tags (Scope): '' expected type 'string', got unconvertible type 'map[string]interface {}'
* module.nsg.azurerm_network_security_group.ABC_NSG_by_name: tags (Scope): '' expected type 'string', got unconvertible type 'map[string]interface {}'
Create resources with tags referenced via remote statefile.
Works only if Key for tag map does not contain "." in statefile.
I've seen an issue like this before. As I recall, the resolution was that you cannot pass a dictionary in for a configuration block like this. In a small subset of cases, it appears to work ok... but internally, it's passing the wrong type around.
I wish I could find the issue where I first saw this... it explained this much better than I ever could.
Thank's for your reply. But still this leaves me puzzled, cause when I play around with the statefile and remove the . from the output variables, everything works out fine. So it's not that dictionaries are broken in general for this case.
It's not that dictionaries are broken, it's just that interpolating a dictionary as a configuration block should not work at all. But the generalized HCL language doesn't understand the specific structure of the resource, so it constructs the resource as if it were valid.
But the types being passed around under the hood are not valid when you do this. That's why you're getting an obscure-looking Go typing error.
Hi @janboll! Sorry for this broken behavior, and for the slow response.
The problem you reported here has the same root cause as #11534, which was recently closed. The fix for this will be included in the forthcoming v0.12.0 release. I left some longer notes in the other issue from my verification of the fix against the v0.12.0-alpha1 build.
Thanks for reporting this, and sorry again for the slow response.
I'm going to lock this issue because it has been closed for _30 days_ โณ. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.