-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
Feature: Expose variable for state file location #17009
Comments
This is an interesting idea. It's especially useful since you can't use interpolation in the backend configuration so you can't simply construct the tfstate path and pass it around without wrapping your TF with a shell script. That's basically what we do. We have to construct our path in a shell script that calls Terraform. With this method, we can pass in the path as a variable and use it in tags or consul keys, etc. Maybe a more general feature would be to allow backends to have attributes that expose all the configuration details including TF version. |
Hi @jhmartin! Thanks for this suggestion. Am I understanding correctly that your goal here would be to include the state file location in, for example, AWS resource tags, and other similar metadata on other systems? This is an interesting idea! So far I think most users have just used the symbolic workspace name rather than the full state location, and then derive the state locations systematically from the workspace name, but including the exact location in there is an interesting variant on that which does indeed make things more explicit and self-documenting. Currently the backend API doesn't allow Terraform Core to recognize the location where the state is stored, so we'd need to adjust that first. However, there is another issue here somewhere (sadly I wasn't able to find it after a quick search) for returning such a value to be displayed in the UI after apply, where Terraform today shows the local filename on the |
Hey! I think this feature can save hundreds of hours of engineers' time while backtracking the source of the resource deployment. Any progress or updates here? |
It would be useful if state backends exposed a variable identifying the location of the state. This would be useful in tagging resources to backtrack where the associated state file is stored.
For example, if multiple groups are sharing an aws account, and have individual s3 buckets for their state store. The variable would contain something like
provider:location
sos3:bucket/prefix/key
. With appropriate tagging it'll be much simpler to reverse-engineer what objects belong to what templates and stacks.The text was updated successfully, but these errors were encountered: