Terraform: Allow interpolation in module names

Created on 27 Dec 2014  ยท  13Comments  ยท  Source: hashicorp/terraform

Apologies if this does not make sense.. I am new to terraform and the use of interpolation in module names makes sense to me coming from other dev ops tools.

For example, when I include the following in my .tf:

resource "aws_route53_record" "${var.app_name}" {
   zone_id = "${aws_route53_zone.primary.zone_id}"
   name = "${var.host}.${var.domain}"
   type = "A"
   ttl = "300"
   records = ["${aws_eip.${var.app_name}.public_ip}"]
}

Terraform will show a warning/error: aws_route53_record.${var.app_name}: module name can only contain letters, numbers, dashes, and underscores. I think it would be sensible to allow interpolation in module names, you could then have a template where these instance names are passed by variable, resulting in a simpler, more generic template.

thinking

Most helpful comment

I want to build dynamic environments from a feature branch let's say. Would be nice to just change a prefix and have a completely identical yet separated environments. This feature could be very useful for such cases.

All 13 comments

I'm looking to do the same thing, but am left wondering whether it's just a case of "you're doing it wrong".

We're building in a microservices world and have a number of frequently occurring infrastructure patterns (http behind ELBs, clusters of message processors, etc.). I'm essentially trying to templatize this for spinning up similar services.

@mpareja See #1114 for a good discussion, too.

@mitchellh Right on! This was indeed a case of "you're doing it wrong". Using multiple module blocks with different names/input variables has proven to be the way to go. Thanks for the quick support, I really appreciate it given how busy I'm sure you are.

I think Terraform's existing module/namespacing (and related functionality/best-practices) are well suited to cover here, and I am not sure I can still justify what was originally proposed. Modules and the best-practices surrounding them, are now much more clear to me. @mitchellh thanks for yet _another_ fantastic product.

That said, I'm wondering about how this relates to a more liberal use of .tf as templates with conditionals and loops? It would be nice to work with count on more than just a few types. Does this make sense?

I agree, I think this isn't ever an intended use case, just due to a lack of good documentation on the way modules are namespaced away. I'll try to make that better. Closing :)

@ketzacoatl Conditionals/loops are something that we're still "thinking" on. Please feel free to share your use case to help fill our library of use cases so we can make the best solution if we ever do so.

Is there any planned re-consideration into this issue? Utilizing a dynamic resource name is valuable when using a service as a 'driver'.

This would help out when using a service like AWS ECS and managing multiple task definitions with minimal differences like port mappings.

+1 @listenrightmeow. I have a similar concern in managing multiple sns topics.

I have a use case that I can't seem to accomplish without some sort of looping.

I am building AWS ECS backed infrastructure, and I would like to be able to define clusters dynamically, passing them as a variable. I want to be able to build an arbitrary number of clusters, each with its own number of EC2 instances and instance types.

I can build the clusters as I need, but I have to explicitly add EC2 resources to each cluster.

This is deal-breaker for me in regards to this project, since I need to be able to add those EC2 resources dynamically.

Hi,

Having the resource name dynamically will be very helpful in order to create multiple instance with different name like below

variable "instance_ids" {
  type = "map"
  default = {
    "0" = "m1"
    "1" = "m2"
    "2" = "m3"
  }
}

"aws_spot_instance_request" "${lookup(var.instance_ids, count.index)}" {
    count = "3"

}

Please let me know is there any workaround to achieve this.

Thanks,

I need this too....
resource "aws_security_group_rule" "${var.sg}" {
....
resource "aws_security_group_rule" "${format("%s-%d",var.sg, count.index +1)}" {
....

Here's my case: key pair with a name exist in another tenant - as I have permissions to see it I get this:

Error applying plan:

2 error(s) occurred:

  • openstack_compute_keypair_v2.uc14_keypair: Error creating OpenStack keypair: Expected HTTP response code [200] when accessing [POST http://10.164.138.12:8774/v2/c4273ed6e9dd4767b15b05266db0b01f/os-keypairs], but got 409 instead
    {"conflictingRequest": {"message": "Key pair 'uc14_keypair' already exists.", "code": 409}}
  • openstack_compute_instance_v2.uc14_instance: Error creating OpenStack server: Invalid request due to incorrect syntax or missing required parameters.

How can I possibly avoid name conflict if I'm using same script in multiple tenants ?!
I have parameters in variables.tf, but no way of using them here...

I want to build dynamic environments from a feature branch let's say. Would be nice to just change a prefix and have a completely identical yet separated environments. This feature could be very useful for such cases.

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

zeninfinity picture zeninfinity  ยท  3Comments

franklinwise picture franklinwise  ยท  3Comments

rkulagowski picture rkulagowski  ยท  3Comments

ketzacoatl picture ketzacoatl  ยท  3Comments

carl-youngblood picture carl-youngblood  ยท  3Comments