Count referring to count parameter of other resources?

[sethp-jive]

I've looked for an open issue describing this use-case, but while there's a lot of tickets around count parameters in general I didn't quite find one that talked to my example. If this is a duplicate of something that exists, I'm sorry!

In any event, I have the volition to define a config in the following way:

resource "null_resource" "a" {
  count = 1
}

resource "null_resource" "b" {
  count = "${null_resource.a.count}"
}

But currently I see the following error:

Error configuring: 1 error(s) occurred:

* strconv.ParseInt: parsing "": invalid syntax

Or alternatively, if A has been created ahead of time:

Error configuring: 1 error(s) occurred:

* strconv.ParseInt: parsing "${null_resource.a.count}": invalid syntax

These are null resources to make the example minimal, but I think the use-case applies broadly to "link objects" (like, aws route table associations or ebs attachments). In this example, A might represent some number of resources that B links to a third static position (e.g. a VPC level route table or a single instance). In this case, having a number of link objects that differs from the number of resources would probably be considered an error (more links would wrap around and try to use the same resource twice, and more resources would leave unused capacity).

What I've seen elsewhere is using a variable, i.e. "var.a_count", in both places. While that does work, it feels a bit weighty to require a global variable name to factor out a count from two places to describe the fact that those two resources should vary together. Directly referencing the count meta-parameter would seem, to me, to more clearly demonstrate the relationship.

I've found elsewhere ( #1497 (comment) ) that the general problem of "count interpolation" is complicated due to its inability to refer to computed values. However, as long as this restriction is in effect referencing another resources' count parameter would still be a static pre-configuration value (i.e. like a variable), so it may prove easier to implement than the general computed counts problem.

[apparentlymart]

In the current implementation, the count attribute is special in that its validation specifically checks that no interpolations other than variables are used. You're right that in principle Terraform should be able to reference any non-computed attributes, but currently Terraform doesn't allow this because it lacks infrastructure to help the user work through complex dependency situations that require multiple steps. In #4149 we're discussing an architecture change that should ultimately allow both computed and non-computed values for count, computed values handled by requiring multiple partial Terraform runs to converge on the desired outcome.

However, another issue in your example that won't be addressed by that proposal is that count is not a resource attribute in the same sense as many other attributes are. Instead, it's handled as a special case.

At present, a top-level variable is the only working approach for what you want to do here. #4149 will partially solve it, but I think further work would be required to make the count attribute interpolatable.

[sethp-jive]

However, another issue in your example that won't be addressed by that proposal is that count is not a resource attribute in the same sense as many other attributes are. Instead, it's handled as a special case.

I did notice that; creating an output with a value of count, e.g.

output "out" {
  value = "${null_resource.a.count}"
}

caused the output to disappear entirely – no error message, just no output. I vaguely recall having seen this behavior before when outputs' values can't be interpolated for some reason, but perhaps that's a different issue?

In any event, thank you for the prompt and thoughtful response!

[ndimiduk]

Is a feature like this required in order to, for example, create count ec2 instances and then register forward and reverse dns entries for each of them? Is there some way to accomplish this currently?

[mitchellh]

This works now!

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