You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is similar to a tagging template that we define for our AWS resources, and can then be "inherited" by various modules built by other teams. They simply link to this template in their workspace and the tags become available as local.tags based on the vars that define that workspace.
This is fine for some modules with only one resource, but is less than ideal for modules that define multiple resources. A good example is dynamodb tables, say a module creates two tables:
Using the tagging template as defined above both of these tables will end up with the same generic Name tag which is not ideal. This can be worked around by overriding the Name tag in the module, eg:
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.
ghost
locked and limited conversation to collaborators
Jul 25, 2019
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Consider this template for AWS tags defined as a local:
This is similar to a tagging template that we define for our AWS resources, and can then be "inherited" by various modules built by other teams. They simply link to this template in their workspace and the tags become available as local.tags based on the vars that define that workspace.
This is fine for some modules with only one resource, but is less than ideal for modules that define multiple resources. A good example is dynamodb tables, say a module creates two tables:
Using the tagging template as defined above both of these tables will end up with the same generic Name tag which is not ideal. This can be worked around by overriding the Name tag in the module, eg:
however it would be nice if this could be made simpler and be done by inference instead.
Are there any plans to extend the self variable functionality so that it works outside of provisioners?
eg
what would also be really nice would be if self variables could be defined in locals and load lazily. so in my locals.tf i could do something like:
and then have self.id only be evaluated when it's processed inside a resource block.
This would make it easy to create dynamic tagging templates that can be easily used by other teams without much effort.
The text was updated successfully, but these errors were encountered: