Depends_on for "count" created resources

[ljsommer]

Use-case:

• VPC routes all egress HTTP traffic through a Squid proxy (one per AZ)
• Each route table has a 0.0.0.0/0 rule to send traffic to the ENI of the Squid server
• Route rules fail to re-create whenever the instance that owns the ENI is rebuilt/created (error below)
• Attempted solution: depends_on a route53 record that is created for each Squid instance
• Depends_on cannot be assigned to resources that are created with a 'count' operator

Request: depends_on to accept either a ${element(aws_route53_record.*.thing, count.index} structure, or at the very least accept resources as they show up in your terraform.state file.

For reference, this is how resources show up in terraform.state that were created with a 'count' operator:
"aws_route53_record.squid_server.0"
I think that depends_on should accept resources that were created in this manner.

This is the error that I am receiving without having the ability to set a dependency in this manner:
"aws_route.private_proxy.0: InvalidParameterValue: Invalid value 'i-0ad9841712b0de0f8' for instance ID. Instance is not in a VPC."

[apparentlymart]

Hi @ljsommer,

Right now we only support depending on the whole set of instances represented by a single block, like this:

  depends_on = ["aws_route53_record.squid_server"]

This is because internally the counted instances behave as a single node in the graph. In most cases depending on the set of instances as a whole is sufficient, and it sounds like it should be in your case too if I'm understanding correctly.

In the past there was some design work done to make individual counted instances be separate nodes in the graph for other reasons, and doing that would likely enable what you requested here, but unfortunately there is some other more fundamental work required before that can be supported. However, this does seem like a reasonable use-case so I'll leave your issue here to represent it and we can revisit it once we're in a better spot to be able to support it.

[ckyoog]

Hi @apparentlymart
I have seen you guys mentioned in different issues (#17156, #10363, #7034, etc) about revamping the configuration language (is it hcl2?), which is a very great news. I look forward to it very much. Just wanna know if you guys have a demo or any schedule to release the new implementation? Not pushing, just curious.

[tdmalone]

In most cases depending on the set of instances as a whole is sufficient

One of the cases where it isn't is where you have count set to 0 - for example to disable a particular resource in a module variable.

[apparentlymart]

Hi @tdmalone,

In that case there is still a node in the graph representing the resource, which then becomes a no-op when it is visited, so it should still be valid to specify such a resource in depends_on. If you have found that this doesn't work then that sounds like a bug, separate from this issue.

[apparentlymart]

Hi all! Sorry for the long silence here.

For the original use-case mentioned here, I think the answer for now is to depend on the resource as a whole rather than on a specific instance of it. That has the same effect for Terraform's graph construction anyway, since individual instances do not become separate graph nodes until the apply step.

    depends_on = ["aws_route53_record.squid_server"]

As I noted above, this works even if the resource count is zero, because the dependency is on the resource itself, not any particular instance of it. When count = 0 you end up with a resource with no instances, so it's still possible to depend on that resource, which ends up just creating a graph node that is essentially a no-op when visited.

I verified this in the v0.12.0-alpha4 prerelease build with the following configuration:

variable "instance_count" {
  default = 0
}

resource "null_resource" "a" {
  count = var.instance_count
}

resource "null_resource" "b" {
  depends_on = [null_resource.a]
}

For 0.12 we've added explicit support for accepting individual constant instance references in depends_on too:

  depends_on = [null_resource.a[0]]

During planning this still gets processed like depends_on = [null_resource.a], depending on all the instances, since individual instances do not exist in the planning graph. However, if we make changes to the graph handling in future to do the expansion in a different way we may be able to make use of this additional detail. In practice it shouldn't be necessary to do this in normal situations, including the one given in the original issue here.

Based on what was discussed here, I think the original use-case is addressed, albeit in a different way than suggested, and so I'm going to close this out. If referring to the resource as a whole doesn't address the original problem of creating a dependency between the Route53 record and the ENI, it's likely that there's some other bug here which we can investigate separately.

Thanks for opening this feature request, and sorry again for leaving it here unattended for so long.

[mikearruda]

@apparentlymart Your solution doesn't appear to be working for me. I have a null resource that depends on a second instance being created, however it is always running even when the second instance doesn't exist? Any ideas?

resource "aws_instance" "test" {
  count = 1
}

resource "null_resource" "test" {
  ...
  depends_on = ["aws_instance.test[1]"]
}

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