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

Autoload *.tfvars in the same way as *.tf (allow inheritance) #1084

Closed
radeksimko opened this issue Feb 28, 2015 · 11 comments · Fixed by #13306
Closed

Autoload *.tfvars in the same way as *.tf (allow inheritance) #1084

radeksimko opened this issue Feb 28, 2015 · 11 comments · Fixed by #13306

Comments

@radeksimko
Copy link
Member

There's currently just one static file - terraform.tfvars where user can place custom settings, but I was thinking that there might be need for more versions of this file, e.g. per environment or per user who's executing it.

The idea is to load all *.tfvars alphabetically, so that user can have e.g. 01-user.tfvars in .gitignore and keep 00-default.tfvars in the repository.

This would generally allow inheritance between these files.

@mitchellh
Copy link
Contributor

This is actually a pretty decent idea. Not sure why we made it terraform.tfvars specifically. I'll think about it. Thoughts, @phinze ?

@derek-adair
Copy link

+1

@phinze
Copy link
Contributor

phinze commented Mar 2, 2015

Yeah I'm +1 for this as well. We'll need to spec and document the behavior on collisions, and we may also want to provide some UX to inspect variables.

We'll need to think about if we're ever going to support complex types (lists, mappings) as input variables. If so, we'll have to consider the inheritance behavior for those types.

@mitchellh
Copy link
Contributor

@phinze I think as an early implementation, any later file just overrides the earlier. We can define more complex types in the future. But I think the easiest will just be that top-level keys just override earlier top-level keys.

@mitchellh
Copy link
Contributor

@phinze More reasons why this makes sense initially: we support multiple -var-file flags. I think wes hould just treat it as if the person just appended those on there.

@phinze phinze added the easy label Mar 2, 2015
@phinze
Copy link
Contributor

phinze commented Mar 2, 2015

Oh yeah - initial impl should be easy then. 👍

@chrisferry
Copy link

👍

@radeksimko
Copy link
Member Author

I plan to look at the implementation, just wanted to ask for feedback regarding this:

Shall we ignore any *.tfvars starting with dot (.) as that's a common behaviour in Unix and more importantly it could be useful in certain situations?

I currently do have a very simple script that takes a "tfvars template" and fills in some known variables, typically external IP address taken via curl http://ipinfo.io/ip and I obviously want to prevent such template from autoloading as it's only template. If I don't take the template and don't generate anything, I still want to leverage the nice TF feature of interactive prompt.

I don't mind sticking to any different convention, but I was thinking that .terraform.template.tfvars could be a nice one?

@mitchellh
Copy link
Contributor

@radeksimko I think we should ignore any files in the same way we ignore *.tf files. There is a isTemporaryFile non-exported helper in config package. I think we should perhaps make that public, add to that one thing over time, and use that to figure out what to ignore and what not to ignore. That way what is ignored for tf is uniform with `tfvars.

@matti
Copy link

matti commented Oct 6, 2016

Is this still on the roadmap?

@ghost
Copy link

ghost commented Apr 8, 2020

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 ghost locked and limited conversation to collaborators Apr 8, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants