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"
}
Add ability to access the module name inside the module file via a new variable, for example via ${parent.name} 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.
Man, I really could use this feature !!!!
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.
It would be very useful, especially to tag resource. Also, we could expand this request to resource items as well.
uniqueness of module name could be very useful for every cattle deployments with similar stacks and sharing resource (s3 example..)
+1
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.
@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.
Bumping, and another suggestion could be "${../aws_subnet.main-public-1.id}"
+1
+1
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.
Most helpful comment
@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.