search

hashicorp / terraform

Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.
https://www.terraform.io/
Other
42.71k stars 9.55k forks source link

Feature: Expose variable for state file location #17009

Open jhmartin opened 6 years ago

jhmartin commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 months ago

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?