config: add select function

[thegedge]

There's a lot of activity in #1604, so conditional behaviour built into terraform core appears to be a much-desired request. In one of my comments in that thread I showed a way to evaluate a ternary – if foo == "spam" then bar else baz – using replace:

replace(replace(var.baz, replace(var.foo, "/^spam$/", "/^.*$/"), ""), "/^$/", var.bar)

Not a pretty beast, but we've been writing it. We were going to create a module to compute this for us, but feel that a module was too much, so I thought I'd propose this select function (note: feel free to propose a better name), as a way to avoid writing the nasty expression above. Some use cases for us:

1. We have a module to create a chef-managed aws_instance. If we decide to place it in a private subnet then we need to make sure the connection goes through a bastion and uses the private ip. We use a ternary to do this.
2. Setting the backup retention period of an RDS instance based on whether or not it's a read replica.
3. Dynamically creating reflexive security group rules (i.e., ports on which members of an SG can talk to each other on) based on whether or not a variable is empty.

[jen20]

Hi @thegedge! Thanks for submitting this PR. I think if we're going to merge this, we need to consider how it might evolve in the future with respects to syntax. @phinze, @mitchellh and @catsby, do you have any thoughts on this?

[thegedge]

I should mention that a combination of the following issues would probably give the same result:

• Default value for map variables #2312 → default value for maps
• Variable references within other variable declarations #2727 → interpolations in variables

With those two you could perhaps do something like this:

variable "select" {
  spam = "bar"
  * = "baz"
}

resource "spam" "eggs" {
  a = "${lookup(var.select, var.foo)}"         // if "star" defaults for maps
  b = "${lookup(var.select, var.foo, "baz")}"  // if default value supported in lookup

Note that this example doesn't make use of #2727, but it would be something we'd need.

[josephholsten]

@phinze, @mitchellh this is ready for your 👀, has tests, doc & passes

[phinze]

The implementation here looks good! But I'm a little worried about potential "flag sprawl" by adding this feature. Picturing possible ways you might want to filter terraform show output, I can think of -resource-names, -module-names, etc., not to mention the negation side of all those options.

I'm thinking it might be a better strategy to try to address terraform show output filtering in a more holistic way. Two ideas:

(a) Add a JSON output format to terraform show, which would let users slice and dice the output with something like jq
(b) Support the full -target syntax on terraform show which would keep things consistent but allow scoping the output.

In order to do filtering equivalent to this, you'd need something more like (a).

[thegedge]

@phinze Did you mean to leave that comment on #3170?

[phinze]

@thegedge whoops! Probably PEBCAK. Meant for #4232. Copying. 🙈

[thegedge]

@phinze Any any thoughts on this PR? Are there things in the pipeline to make this PR unnecessary? It's been lying around for quite some time, so I'd like to either get it merged or close it off 😃

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