New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Access parent module name as a variable #8706

garo opened this Issue Sep 7, 2016 · 9 comments


None yet
Copy link

garo commented Sep 7, 2016

When defining a module you give the instantiation a name ("foobar"). Example:
module "foobar" { ... }

The problem is that there is currently no way to access the name using a variable. If for example you have a module which will create an aws_instance and you would like to use the module name also as the hostname, you need to retype the hostname into a variable:

module "foobar" {
  source = "..."
  hostname = "foobar"

Proposed solution

Add ability to access the module name inside the module file via a new variable, for example via ${} or something similar. In this example, it would remove the need to add the "hostname" variable, but instead inside the module the "foobar" name could be accessed directly as a variable.


This comment has been minimized.

Copy link

johntdyer commented Sep 26, 2017

Man, I really could use this feature !!!!


This comment has been minimized.

Copy link

plombardi89 commented Oct 11, 2017

This would be super useful since module names need to be unique and it can help ensure uniqueness when deploying a bunch of modules with slightly different configuration. You could key off the module name for example to ensure unique S3 paths.


This comment has been minimized.

Copy link

mlsmaycon commented Oct 27, 2017

It would be very useful, especially to tag resource. Also, we could expand this request to resource items as well.


This comment has been minimized.

Copy link

proj4spes commented Dec 13, 2017

uniqueness of module name could be very useful for every cattle deployments with similar stacks and sharing resource (s3 example..)


This comment has been minimized.

Copy link

ntman4real commented Feb 20, 2018


@apparentlymart apparentlymart added config and removed core labels Feb 21, 2018


This comment has been minimized.

Copy link

apparentlymart commented Feb 21, 2018

Hi all! Sorry for the long silence here.

After spending some time reflecting on this, at this time I think we will say no to this feature. One of our core design tenets for the configuration language is "explicit is better than implicit", and if we were to allow modules to see the name that was used by the caller then this would create non-obvious implicit extra requirements on that module name. Today the module name can be freely chosen by the caller with no constraint other than the syntax constraints imposed by Terraform itself.

Due to this design goal, it's a feature that the hostname must be explicitly specified as a separate argument, since that makes it very clear to the caller what this value will be used for and allows any constraints on that argument to be explicitly documented in its description. Duplication is not necessarily bad if it makes the configuration easier to read, since configurations are generally read many more times than they are written.

Please note also that module names are not globally unique -- they are unique only within the context of one module -- so it would not in general be safe to use them in any situation where global uniqueness is required, and so additional arguments would often need to be provided anyway in order to ensure uniqueness across multiple calls.

I can see the idea that within a particular team you may wish to require the module name and the hostname to match as a matter of policy. At the moment Terraform does not have any features for easily enforcing such policies through local tools, but this is likely to become possible in future via plumbing commands intended to make it easier to "inspect" configuration from external scripts. We do not have a specific timeline for this since it's just one idea in a list of many, but there are several use-cases that would benefit from it and so will almost certainly happen eventually.

I'm sorry to show up here after all this time with bad news, but I hope the above rationale gives good context for this decision. Given that we do not plan to move forward with this feature, I'm going to close this issue. Thanks again for taking the time to file it.


This comment has been minimized.

Copy link

omeid commented Mar 12, 2018

@apparentlymart While I agree with the argument for not using the module name for hostname or any other identifier for that mater, I think being able to access the name to use it as parts of tags is very helpful for example.


This comment has been minimized.

Copy link

damusix commented May 13, 2018

Bumping, and another suggestion could be "${../}"


This comment has been minimized.

Copy link

o6uoq commented Sep 26, 2018


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment