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

config: Add getenv interpolation function #14166

Closed
wants to merge 1 commit into from

Conversation

vancluever
Copy link
Member

@vancluever vancluever commented May 2, 2017

I think that there was possibly some discussion on supporting more general fetching of environment variables in #1621 by supplying an env. variable namespace. Barring that though, I think the interpolation function API is a very good fit for supporting this use case, and seems like an easy win!

Commit message below. I've also supplied docs not just in the function reference but also in the general environment variables configuration section as well.


This is a very simple function that just passes off to os.Getenv in the Go standard library. However, it adds some first-class support for fetching environment variables without having to supply them as variables being passed in to Terraform, supporting some use cases where doing so would unnecessarily complicate tooling or would be prohibitive altogether.

This is a very simple function that just passes off to os.Getenv in the
Go standard library. However, it adds some first-class support for
fetching environment variables without having to supply them as
variables being passed in to Terraform, supporting some use cases where
doing so would unnecessarily complicate tooling or would be prohibitive
altogether.
@apparentlymart
Copy link
Member

apparentlymart commented May 3, 2017

Hi @vancluever! Thanks for this great work, as usual.

This is a tricky one since it's actually very intentional that we don't have a convenient way to access environment variables like this. The idea is to ensure that the input to a module is only via its variables, thus making the module's interface explicit.

Allowing arbitrary reads of environment variables would allow child modules to access them, which would in turn allow a "backdoor" for passing variables directly to a child module without the knowledge of its caller.

The discussion in #1621 is skirting around what we'd like to do here, which is to mimic Packer's design where environment variables can be used only to populate variables in the root module. In Packer's case that is done by making the env function usable only in that context, so if we were to implement an env. interpolation namespace in Terraform then the same constraint would apply there.

For now, the TF_VAR_foo environment variable scheme intended to address many of the use-cases that such an interpolation would serve. The main thing it can't do is set a variable to the result of some function applied to the environment variable value, but given that interpolation isn't currently allowed in variables anyway it's possible to achieve all of the same things using a wrapper script to pre-set TF_VAR_foo-style variables based on any existing non-prefixed variables.

So with all of that said, I'm afraid we're not going to move forward with this, not because it isn't good code but because it runs against an intentional philosophy for the design of Terraform. The env. interpolation style still seems like the right long-term solution, but we want to take the time to design that comprehensively so we can define well how it would interact with existing Terraform mechanisms.

Thanks again!

@vancluever
Copy link
Member Author

vancluever commented May 3, 2017

Fair enough @apparentlymart. Funny enough, I tried to see if this had precedent and kind of suspected that this might be the case. I was surprised to see it hadn't been proposed in an issue or PR (as I could see anyway) so I thought I'd put it out there. At least now there's a reference ;)

Thanks anyway!

@ghost
Copy link

ghost commented Apr 13, 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.

@hashicorp hashicorp locked and limited conversation to collaborators Apr 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants