Attribute-level circular dependency detection

[mikeclayton]

Current Terraform Version

1.0.5

Proposal

Enhance circular dependency detection to allow some scenarios where terraform plan currently throws an error, but could actually resolve values.

For example:

resource "azurerm_virtual_machine" "my_az_vm" {
  name                  = "my-az-vm"
  network_interface_ids = [
    # creates a dependency on my_az_vm_nic
    azurerm_network_interface.my_az_vm_nic.id
  ]
  ... etc ...
}

resource "azurerm_network_interface" "my_az_vm_nic" {
  # creates a dependency on my_az_vm
  name = "${azurerm_virtual_machine.my_az_vm.name}-nic"
  ... etc ...
}

fails with the following error:

Error: Cycle: azurerm_network_interface.my_az_vm_nic, azurerm_virtual_machine.my_az_vm

In this case, some attributes in my_az_vm refer to attributes in my_az_vm_nic and vice versa, so there's a circular dependency detected at the resource level, but strictly speaking there's no circular reference at the attribute level because the value of azurerm_virtual_machine.my_az_vm.name could potentially be determined during the plan phase (here it's a literal string, but I could imagine it being an arbitrary expression which references other attributes and invokes arbitrary Configuration Language functions as long as it doesn't create an attribute-level cycle).

To work around this at present I've created a local value and referenced that in both resources to break the cycle:

locals {
  virtual_machine_name = "my-az-vm"
}

resource "azurerm_virtual_machine" "my_az_vm" {
  name                  = local.virtual_machine_name
  network_interface_ids = [
    # creates a dependency on my_az_vm_nic
    azurerm_network_interface.my_az_vm_nic.id
  ]
  ... etc ...
}

resource "azurerm_network_interface" "my_az_vm_nic" {
  name = "${local.virtual_machine_name}-nic"
  ... etc ...
}

but it would nice to be able to use the original version above ^^^.

This might all have implications on other operations - e.g. terraform destroy would need to be able to decide which resource to destroy first, so I realise this isn't just a simple request, but your thoughts welcome...

References

A search in this repo for "cycle issues" (https://github.com/hashicorp/terraform/search?q=cycle&type=issues) finds a couple of related (but not identical) issues:

• Feature: Allow circular dependencies in resources #27188 - I think this is talking about true unresolvable resource-level cycles - there's no code example, but I'm presuming it means something like:

resource "azurerm_virtual_machine" "my_az_vm" {
  # creates a dependency on my_az_vm_nic
  name = azurerm_network_interface.my_az_vm_nic.name
  ... etc ...
}

resource "azurerm_network_interface" "my_az_vm_nic" {
  # creates a dependency on my_az_vm
  name = azurerm_virtual_machine.my_az_vm.name
  ... etc ...
}

I'm not really asking for this scenario to be allowed, just attribute-level "cycles" that can be actually resolved like my first example ^^^.

• Allow referencing one instance of a resource from another instance of that same resource #22517 (comment) - this comment notes the behaviour described above - i.e. resource-level cycle detection as a deliberate feature of Terraform:

Terraform is working as intended here because the references are resolved between the resource blocks as a whole rather than between the individual instances.

Tracking attribute-level cycles rather than resource-level cycles could potentially resolve this issue as a side-effect, which would be a happy accident, but I'm not specifically asking for that to be included in this feature request:-).

• resource-instance-scoped named local values #3267 - the changes required to track attribute-level cycles might also feed into allowing resource self attribute references. since they'd both need to be able to do some new attribute-level processing. This might be the biggest part of the work for self and my feature request - see resource-instance-scoped named local values #3267 (comment)

arguments inside a block can be evaluated in any order while implementing this feature would effectively make the arguments themselves a dependency graph, which is a considerably more complex design

[jbardin]

Hi @mikeclayton,

Thanks for filing the issue. While in the case presented above, it would be theoretically possible for terraform to break the cycle and evaluate that specific value, there would still be no way to plan or apply the resources because a suitable order cannot be determined.

References between resources not only allow one to share information between resources, but they also declare the dependencies required for planning and applying those resources. The references you are using here would be roughly equivalent to adding each resource to a depends_on list in the other, which should make it more clear why that cannot work. When multiple resources both depend on the same value, the correct solution is to break that value out into an independent location to prevent a cycle, which means what you have presented as the workaround is the expected structure of the configuration in this case.

Since this is working as intended, and there really isn't any way to infer references without creating dependencies within the design of Terraform, I'm going to close this out. If you have more questions, it's better to use the community forum where there are more people ready to help.

Thanks!

[github-actions]

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.