Skip to content
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

Open
jhmartin opened this issue Dec 29, 2017 · 3 comments
Open

Feature: Expose variable for state file location #17009

jhmartin opened this issue Dec 29, 2017 · 3 comments

Comments

@jhmartin
Copy link

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 so s3:bucket/prefix/key. With appropriate tagging it'll be much simpler to reverse-engineer what objects belong to what templates and stacks.

@natefaerber
Copy link

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.

@apparentlymart
Copy link
Member

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 local backend. We could perhaps use the same underlying feature for both, although the way we'd envisaged that feature working was to return something human-display-oriented rather than machine-oriented: S3 has a convenient pseudo-URI scheme that can be used to get the best of both worlds, but other backends such as consul don't have a convenient machine-readable string representation.

@DmytroRomantsovM
Copy link

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?

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

No branches or pull requests

4 participants