Intermediate variables (OR: add interpolation support to input variables)

[mrwilby]

Not quite sure how to express this properly.

Input variables today cannot contain interpolations referring to other variables. I find myself bumping up against this now and then where I'd prefer to define a "default" value for an input variable based upon a composition of another input variable and some fixed string.

If we could interpolate values inside default properties of input variables OR, terraform supported some kind of internal transitive intermediate variable which only exists in order to act as a binding point between inputs and other interpolation expressions I could accomplish what I want without having a lot of redundancy in inputs.

Slightly related, but I also long for the ability to reference the input values of a module (not just the outputs) because this is often where I tend to create such bindings. Of course, I can propagate the input to the module all the way through the module and emit as an output but that gets quite repetitive and clunky after a while.

[apparentlymart]

Intermediate variables have been a desire of mine too.

In one particularly tricky spot (using the CIDR functions for network planning) I worked around this by creating a module whose entire purpose is to pass through a value verbatim:

variable "value" {}
output "value" {
    value = "${var.value}"
}

which I then instantiated for each "intermediate variable" I needed:

module "example" {
    source = "..."
    value = "${cidrsubnet(....blahblahblah)}"
}

/// ...

resource "aws_vpc" "example" {
    cidr_block = "${module.example.value}"
}

It's clunky, not least because terraform get then wants to create a separate copy (or symlink) of this "identity module" for each usage. But it got me out of a hairy spot.

[jonapich]

I have spent the better of the last 3 days trying out terraform. In practically all my attempts, I have bumped against this shortcoming; input variables are totally static and cannot be baked from other input variables.

Maintainability and readability is highly impacted by this limitation. Every time a calculation must be repeated across several resources, the DevOp is tempted to create a variable out of the calculation so that he can use just the variable and not having to "remember/copy" the calculation everywhere. As the repetitions increase, changing the calculation becomes more and more risky because you must catch it in all the files.

I have seen some of the propositions (such as the data-driven configuration) and while they all look great to me, they don't look like trivial changes and thus, I am afraid they will come in very late.

It looks to me that if the scope of this feature is limited to input variables, it would be a trivial and incredibly useful addition that would immediately raise user adoption and agility/flexibility. I am still trying to figure out how big of a deal breaker this is for our particular scenario.

Here's a very simple scenario:

variable "region" {
  description = "Please choose an AWS region: n - us-east-1, o - us-west-2"
}

variable "regions" {
  description = "internal use - AWS regions map"
  default = {
    n = "us-east-1"
    o = "us-west-2"
  }
}

variable "region_name" {
  description = "friendly name for the selected region"
  computed = "${lookup(var.regions, var.region)}"
}

Maybe it should be a whole new type of resource to make it really easy on the interpreter, and also very easy to deprecate once the data-driven configs are production-ready:

late_binding_variable "region_name" {
  value = "${lookup(var.regions, var.region)}"
}

Of course these should be included in "${var.*}" so maybe the variable needs a new parameter if it's hard to distinguish static values from interpolations when terraform reads the config:

variable "region_name" {
  value = "${lookup(var.regions, var.region)}"
}

In the above example, terraform knows that a variable without a default but that contains a "value" parameter must be expanded last through interpolation. Also, I guess if value is there, it should error out if a default is also included.

Of course, only variables would be allowed into this new interpolation stage. I don't expect them to work if interpolated from modules or resources.

[apparentlymart]

In the mean time since I wrote my earlier comment I found a new workaround, that became possible because of the null_resource changes in a recent release:

resource "null_resource" "intermediates" {
    triggers = {
        subnet_cidr = "${cidrsubnet(....blahblahblah)}"
    }
}

resource "aws_vpc" "example" {
    cidr_block = "${null_resource.intermediates.triggers.subnet_cidr}"
}

This hack has some different pros and cons than the module hack I was using before:

• You don't have to terraform get a bunch of silly do-nothing modules, which is nice.
• Since null_resource is a resource, it generates a bunch of extra noise in diffs whenever the values change, which can be off-putting to those who don't know this pattern.
• You can pack an arbitrary number of "intermediate variables" into a single resource, so it can serve to group together a bunch of intermediates that are related in some way and also reduce the amount of diff noise.

A long-term solution to this could potentially build on the architectural change described in #4149. An implication of that change is making the concept of "computed" more pervasive in Terraform, so that the various complex rules around what kinds of interpolations are allowed in different contexts can potentially be simplified into the three cases "allows all interpolations", "allows all interpolations but causes a deferral when computed" and "allows only non-computed interpolations".

[jonapich]

The null_ressource looks great! Definitely opens the door to better maintainability and readability. The doc is is sort of hidden down there in the providers section, which I haven't had a need for so far. Maybe it deserves a quick mention in the variable interpolation doc?

[igoratencompass]

@apparentlymart amazing, it works! Would have never thought of using null_resource this way, thank you!

[darrin-wortlehock]

@apparentlymart - having trouble grokking your workaround. In your example you reference ${null_resource.triggers.subnet_cidr}. Should that be ${null_resource.intermediates.triggers.subnet_cidr} ? I'm getting an error missing dependency: null_resource.triggers when I try and use your example, but an invalid syntax error when I include intermediates. Thanks.

[apparentlymart]

@darrin-wortlehock yes, sorry... you're right. I've corrected the example to use null_resource.intermediates.

[plombardi89]

I use the template_file resource to do this...

resource "template_file" "environment_fqn" {
  template = "${var.environment_type}_${var.environment_region}_${var.environment_label}"
  lifecycle { create_before_destroy = true }
}

Then you just use rendered to get the value later.

Is there anything wrong with doing it this way? I haven't run into an issue in my limited use of it.

[apparentlymart]

@plombardi89 that's an interesting hack... you're actually creating a template with no interpolations in it, since the interpolations in your string are handled before the template is parsed, and then "rendering" that template.

This has a similar effect to my null_resource example above, but there is a caveat that if any of your variables expand to something that looks like Terraform interpolation syntax then the template_file resource will attempt to expand them, which is likely to produce unwanted results.

As long as it doesn't include any interpolation markers then it should work just fine.

[plombardi89]

@apparentlymart Good point. Not too worried about interpolation markers here, but I guess I could address it with an explicit vars blocks.

[joshrtay]

would really like to interpolate input variables.+1