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

TF 0.6: prompting for values even though default is defined #2592

Closed
nathanielks opened this issue Jul 1, 2015 · 24 comments · Fixed by #2613
Closed

TF 0.6: prompting for values even though default is defined #2592

nathanielks opened this issue Jul 1, 2015 · 24 comments · Fixed by #2613
Assignees

Comments

@nathanielks
Copy link
Contributor

Just updated to 0.6.0 and now variables that have defaults are prompting for a value. Ideally it would use the default value silently. I couldn't find any PR's or issues describing the new behavior. Is this intentional or oops?

@phinze
Copy link
Contributor

phinze commented Jul 1, 2015

@nathanielks thanks for the report! We actually noticed something similar as we rolled 0.6.0 out to Atlas.

I'll do some more testing to figure out where the behavior change is coming from, but in the meantime you can always add the -input=false flag or set the TF_INPUT=0 env variable to opt-out of this behavior.

@phinze phinze self-assigned this Jul 1, 2015
@nathanielks
Copy link
Contributor Author

@phinze aha, thanks for that!

@nathanielks
Copy link
Contributor Author

@phinze would it be helpful if I started documentation on the various env variables? So far I'm aware of:

  • TF_LOG
  • TF_LOG_PATH
  • TF_INPUT
  • TF_MODULE_DEPTH
  • TF_VAR_name
  • TF_DEV
  • TF_QUICKDEV
  • TF_ACC
  • TF_PLUGIN_MIN_PORT
  • TF_PLUGIN_MAX_PORT
  • TF_PLUGIN_MAGIC_COOKIE

@phinze
Copy link
Contributor

phinze commented Jul 1, 2015

@nathanielks yeah might be worth gathering them all into one place - though we should probably categorize them since some are really only for development while others are actually useful to users

@mitchellh
Copy link
Contributor

Agreed with @phinze that we shouldn't doc the dev ones except for perhaps in the README or contributors guide.

@nathanielks
Copy link
Contributor Author

Will do. Where'd you like me to write those up? I can get started on that tonight.

@phinze
Copy link
Contributor

phinze commented Jul 1, 2015

@nathanielks good question! perhaps a new "Environment Variables" page under "Configuration"?

@nathanielks
Copy link
Contributor Author

@phinze that sounds pretty good to me.

@phinze
Copy link
Contributor

phinze commented Jul 2, 2015

I think the relevant code change here is #2502

@phinze
Copy link
Contributor

phinze commented Jul 2, 2015

Okay, so that code change uncovered the core bug here that's been hanging out for some time: terraform is prompting for any variables without values, even if they have defaults set.

Tagged and we'll get this fixed up!

@nathanielks
Copy link
Contributor Author

whoop whoop!

@nathanielks
Copy link
Contributor Author

Okie doke, here's my first go at it: #2601

@RichSteele
Copy link
Contributor

Thanks, just ran into this myself and caused some head scratching for me.

phinze added a commit that referenced this issue Jul 2, 2015
In `helper/schema` we already makes a distinction between `Default`
which is always applied and `InputDefault` which is displayed to the
user for an empty field.

But for variables we just have `Default` which is treated like
`InputDefault`. This changes it to _not_ prompt the user for a value
when the variable declaration includes a default.

Treating this as a UX bugfix and the "don't prompt for variables w/
defaults set" behavior as the originally expected behavior we were
failing to honor.

Added an already-passing test to verify and cover the `helper/schema`
behavior.

Perhaps down the road we can add a `input_default` attribute to
variables to allow similar behavior to `helper/schema` in variables, but
for now just sticking with the fix.

Fixes #2592
@RichSteele
Copy link
Contributor

I'm afraid I'm still seeing this behavior after updating and building locally. In my case I'm using the OpenStack provider and not specifying the openstack.api_key and openstack.endpoint_type which aren't required (according to the docs) but am still getting prompted for them. (I suppose the docs could be wrong, but everything works as expected if I specify blank values for them so I suspect not.)

@phinze
Copy link
Contributor

phinze commented Jul 9, 2015

Hi @RichSteele - this issue was specifically around variables (i.e. variable "foo" {}). That sounds like it might be a bug with provider attributes. Do you think you could open a separate issue with your config? Then we can get it looked at and fixed. 👍

@phinze
Copy link
Contributor

phinze commented Jul 9, 2015

@RichSteele ah I hadn't seen this PR #2626 - will be fixed it 0.6.1!

@RichSteele
Copy link
Contributor

Awesome, thanks, I misread this defect. I hadn't thought to look through the pull requests for it.

@umeshksingla
Copy link

I would like to have an option of asking even if the default is set where simply pressing the enter key takes the default value. Couldn't find anything in 0.11.7, any leads?

@mildwonkey
Copy link
Contributor

@umeshksingla - I haven't seen any requests for that feature; you can open a feature request!

@naumannt
Copy link

@umeshksingla did you ever open a feature request for this? I would also like that feature very much!

@clayrisser
Copy link

👍

@umeshksingla
Copy link

@naumannt @codejamninja I did. Here #18702

@clayrisser
Copy link

@umeshksingla how do you control showing the default or not showing the default?

@ghost
Copy link

ghost commented Oct 11, 2019

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 Oct 11, 2019
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.

8 participants