Module dependency graph constructed incorrectly with list and map input variables

[megakoresh]

If you have a module that accepts e.g. a list of IDs, and you give it the IDs from another module's output, and then try to spawn resources inside the first module.

Terraform Version

0.11.07

Terraform Configuration Files

module "secgroup_web" {
  source = "../../security"
  name           = "Web"
  admin_group_id = "${module.secgroup_admin.group_id}"
}

module "secgroup_mumble" {
  source = "../../security"
  name           = "Mumble"
  description    = "Security group for murmur (Mumble) servers provisioned by Terraform."
  admin_group_id = "${module.secgroup_admin.group_id}"
  allowed_from_groups = ["${module.secgroup_web.group_id}"]
}

output of the module is defined like so

output "group_id" {
  value = "${openstack_networking_security_group_v2.secgroup.id}"
}

input is used in the receiving module like so

resource "openstack_networking_secgroup_rule_v2" "rule_ipv6" {
  count             = "${length(var.allowed_from_groups)}"
  direction         = "ingress"
  ethertype         = "IPv6"
  remote_group_id = "${var.allowed_from_groups[count.index]}"
  security_group_id = "${openstack_networking_secgroup_v2.ports.id}"
}

Note that admin_group_id = "${module.secgroup_admin.group_id}" is correctly processed into dependency graph.

Debug Output

N/A

Crash Output

openstack_networking_secgroup_rule_v2.rule_ipv6: value of 'count' cannot be computed

Expected Behavior

The count should be evaluated after the previous module's output is available

Actual Behavior

Terraform does not include module outputs declared within lists and maps and thus crashes because contents are not available.

Steps to Reproduce

Construct the configuration resembling the above example.

Additional Context

Provider is openstack. There is no workaround for this. Using null_resource has no effect.

References

There is a LOT of open and closed issues about module-on-module dependencies which would solve this, but the ideal solution would be fix this behaviour to be consistent with string type references.

[apparentlymart]

Hi @megakoresh! Sorry for this bug and sorry for the slow response.

The issue you've hit here has the same root cause as #14677, which is now fixed in master and will be included in the forthcoming v0.12.0 release.

[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.