depends_on for data_source

[samber]

Hi guys,

I am using the depends_on parameter on data-source.

provider "consul" {
    address       = "consul:8500"
    datacenter    = "dc1"
}

resource "consul_key_prefix" "job_config" {
    datacenter = "dc1"
    path_prefix = "services/api/nomad-job/"

    subkeys = {
        port=4242
    }
}

data "consul_keys" "read_env" {
    datacenter = "dc1"
    depends_on = ["consul_key_prefix.job_config"]

    key {
        name = "port"
        path = "services/api/nomad-job/port"
    }
}

output "vars" { value = "${data.consul_keys.read_env}" }

It needs to be applied 2 times to get the right output.

[apparentlymart]

Hi @samber. Sorry for the issue here.

I think I remember seeing this issue on here before but I couldn't find it quickly. IIRC the problem here is that Terraform uses computed attributes to decide whether to defer a data source from refresh time to apply time, but an explicit depends_on does not create such a computed attribute and so Terraform thinks it can refresh the data source early.

You're right that this is a bug, but for now I would suggest working around it by adding a "dummy interpolation" to your data resource so that Terraform knows it must defer loading it, if possible. This means finding a computed attribute from the resource to interpolate somewhere into the data resource. I assume your example here is just a contrived repro case, but there's usually something you can interpolate to force Terraform to do the right thing here.

The real fix in the long run would be for the code that decides whether to defer a data source to also check the explicit depends_on, though we'd probably need to make some assumptions here to get useful behavior. At first blush it feels like the right behavior would be to look at all of the depends_on items and verify that they all have a "primary" resource instance in the state. If they don't then we defer, but if we do then we can assume that the resource attributes would've been updated during the refresh pass and so the right value should already be available.

[samber]

Ok, thanks for your fast reply. We will find a work around with a faked computed attribute call.

[jbardin]

@apparentlymart,

I think we can get by with the simpler solution here, and just check for depends_on values (PR submitted). There will only be entries there if the user specifically added them to the config. Since there's no other reason to add depends_on for a data source, I think it should be safe to assume that the user wanted to enforce a "happens before" relationship.

The only issue I can think of with this, is somehow breaking a config where depends_on was needlessly added, and left in because it had no side-effects.

[sanchetanparmar]

I am facing same issue on latest version

Terraform v0.12.6
+ provider.azurerm v1.32.1

Basic Terraform Code

data "azurerm_network_interface" "myterraformnic" {
  name                = "myNIC"
  resource_group_name = "myResourceGroup"
  depends_on = ["azurerm_network_interface.myterraformnic"]
}

output "private_ip_address" {
  value = "${azurerm_network_interface.myterraformnic.private_ip_address}"
}
 
variable "ip_type" {
  default = "Dynamic"
}

resource "azurerm_network_interface" "myterraformnic" {
    name                = "myNIC"
    location            = "eastus"
    resource_group_name = "${azurerm_resource_group.myterraformgroup.name}"
    network_security_group_id = "${azurerm_network_security_group.myterraformnsg.id}"

    lifecycle {
            prevent_destroy = true
    }

    ip_configuration {
        name                          = "myNicConfiguration"
        subnet_id                     = "${azurerm_subnet.myterraformsubnet.id}"
        private_ip_address_allocation =   "Dynamic"

    }
}

If depends_on works for data it can solve Azure Static ip issue as well.

[ghost]

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.