Reading from terraform_remote_state with AzureRM provider

Question

I'm trying to deploy a VNET in one module and store the ID of the subnet in remote state in Azure Blob Storage.

I see that my output seems to be stored correctly in the remote state blob.

The problem arises when I'm trying to read the Subnet ID in another module

terraform {
  backend "azurerm" {
    storage_account_name  = "mystorage"
    container_name        = "tfstate"
    key                   = "terraform.tfstate"

  }
}

resource "azurerm_subnet" "defaultsubnet" {
  name  = "default"
  address_prefix = "10.10.1.0/24"
  resource_group_name = "my-rg"
  virtual_network_name = "my-vnet"
}

output "id" {
  value = "${azurerm_subnet.defaultsubnet.id}"
}

"outputs": {
                "id": {
                    "sensitive": false,
                    "type": "string",
                    "value": "/subscriptions/***/resourceGroups/my-rg/providers/Microsoft.Network/virtualNetworks/my-vnet/subnets/default"
                },

data "terraform_remote_state" "sub" {
  backend = "azurerm"
  config = {
    storage_account_name = "mystorage"
    container_name       = "tfstate"
    key                  = "terraform.tfstate"

  }
}

resource "azurerm_kubernetes_cluster" "aks" {
.....
    agent_pool_profile {
        vnet_subnet_id = "${data.terraform_remote_state.sub.id}"
    }
}

vnet_subnet_id = "${data.terraform_remote_state.sub.id}"

This line fails with the following message:

Error running plan: 1 error(s) occurred:\n\n* azurerm_kubernetes_cluster.aks: Can not parse \"agent_pool_profile.0.vnet_subnet_id\" as a resource id: Cannot parse Azure ID: parse 2019-04-09 15:21:55.916021 +0000 UTC: invalid URI for request\n\n\n"}

Somehow it's casting the subnet ID as Date. And even thought I've found a similar issue here https://github.com/hashicorp/terraform/issues/20147 I'm still not able to apply that workaround to my case.

We used this pattern many times without issues in 0.11.x. Can you share a little more about? Which Terraform version? — Giulio Vian
Sure, we're using 0.11.13 if I'm not wrong, but I'm confident that it's not 0.12 yet. I'll gladly share more info if you give me a hint about what you'd like to know. Thanks :) — maximumfrustration
I checked our code is following the same pattern as yours, so we should look at something else. We use this pattern when producer and consumer code are in different directories; each dir use a different container/key for state. Is this your case? — Giulio Vian
Almost. We use different directories for consumer and producer code, e.g. "modules/azure/vnet" is used for networking modules and "modules/azure/aks" contains our AKS related modules. However, I'm using the same remote state container/key for now. — maximumfrustration

ydaetskcoR ydaetskcoR · Accepted Answer · 2019-04-09T17:38:02

Where possible you should avoid using the remote state data source and use native data sources that work against your provider.

In this case you should use the azurerm_subnet data source instead:

data "azurerm_subnet" "subnet" {
  name                 = "default"
  virtual_network_name = "my-vnet"
  resource_group_name  = "my-rg"
}

resource "azurerm_kubernetes_cluster" "aks" {
  #...
  agent_pool_profile {
    vnet_subnet_id = "${data.azurerm_subnet.subnet.id}"
  }
}

Reading from terraform_remote_state with AzureRM provider

1 Answers