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

Terraform 0.13.1 prompting for variables twice #26027

Closed
Neutrollized opened this issue Aug 27, 2020 · 5 comments
Closed

Terraform 0.13.1 prompting for variables twice #26027

Neutrollized opened this issue Aug 27, 2020 · 5 comments
Assignees
Labels

Comments

@Neutrollized
Copy link

Neutrollized commented Aug 27, 2020

Terraform Version

0.13.1

Terraform Configuration Files

Irrelevant, however it happens with S3 backend as well as local backend (from my testing)

Debug Output

terraform 0.13.1
vs
terraform 0.13.0

Crash Output

EDIT 2: Crash only happens if I try to ctrl+c out of the re-prompt (also mentioned in comment below)

Expected Behavior

Prompt only once

Actual Behavior

Prompted for (all) variables twice.

Steps to Reproduce

terraform init, terraform plan and terraform apply both would prompt for variables twice.

Additional Context

It prompts for all variables twice. So if you have 3 vars that need to be prompted for input, it will re-prompt you for all 3 in the same order. If you have vars in terraform.tfvars defined, then it works as intended and there's no prompting.

EDIT: aside from prompting twice, everything builds (and destroys) as intended.

References

Not a GitHub reference, but does Reddit count? :D https://www.reddit.com/r/Terraform/comments/ihs6hx/terraform_asking_for_input_variable_values_twice/

@mildwonkey
Copy link
Contributor

thanks for reporting this @Neutrollized !

mildwonkey added a commit that referenced this issue Aug 28, 2020
backend, which resulted in users being prompted for input variables
twice. This PR fixes that by setting AllowUnsetVariables to true for the
state context.

Fixes #26027
mildwonkey added a commit that referenced this issue Aug 28, 2020
A recent change to the backend had a side effect of causing all input
vars to be requested twice (due to two calls to `contextDirect`) and
provider input values to be omitted entirely (those were populated
during Validate, but Validate was called on the "extra" context and not
the returned context).

This PR adds a Context.StatelessCopy function which returns a nearly-identical copy of
a terraform.Context with the state "zeroed out", which can then be
Validate()d. A better, future refactor should remove the need for this
function and instead modify Validate() itself to ignore state.

Fixes #26027

I've added tests that confirm both behaviors; I am not sure what test
covers the behavior that lead to this change in the first place but I
did verify locally using the reproduction in the original PR.
@Neutrollized
Copy link
Author

Neutrollized commented Aug 29, 2020

Holy crap. I thought your name looked familiar; I saw you give the talk on Path to Terraform 1.0 during HashiConf EU a few months ago! (Beautiful cat btw)

@Neutrollized
Copy link
Author

Neutrollized commented Aug 29, 2020

Just thought I'd do some more testing on my own and here's some additional info that might be useful to you:

  1. my original terraform files included a backend.tf which used s3 as the TF state backend, but I get the same double prompt bug even if I were to use local state
  2. if I ctrl+c out of a terraform plan (as an example) on the first prompt, I get the expected error of:
var.vpc_id
  Enter a value: ^C
Interrupt received.
Please wait for Terraform to exit or data loss may occur.
Gracefully shutting down...

Error: No value for required variable

  on variables.tf line 4:
   4: variable "vpc_id" {}

The root module input variable "vpc_id" is not set, and has no default value.
Use a -var or -var-file command line argument to provide a value for this
variable

However...If I were to ctrl-c on the re-prompt, I get a Terraform crash instead:

var.vpc_id
  Enter a value: vpc-yyyyyyyyyyyyyyyyyy

var.vpc_id
  Enter a value: ^C
Interrupt received.
Please wait for Terraform to exit or data loss may occur.
Gracefully shutting down...
panic: runtime error: invalid memory address or nil pointer dereference
...
...
...
SECURITY WARNING: the "crash.log" file that was created may contain
sensitive information that must be redacted before it is safe to share
on the issue tracker.

[1]: https://github.com/hashicorp/terraform/issues

!!!!!!!!!!!!!!!!!!!!!!!!!!! TERRAFORM CRASH !!!!!!!!!!!!!!!!!!!!!!!!!!!!

Details from crash log can be found here

Hope this helps!

mildwonkey added a commit that referenced this issue Aug 31, 2020
This pull reverts a recent change to backend/local which created two context, one with and one without state. Instead I have removed the state entirely from the validate graph (by explicitly passing a states.NewState() to the validate graph builder).

This changed caused a test failure, which (ty so much for the help) @jbardin discovered was inaccurate all along: the test's call to `Validate()` was actually what was removing the output from state. The new expected test output matches terraform's actual behavior on the command line: if you use -target to destroy a resource, an output that references only that resource is *not* removed from state even though that test would lead you to believe it did.

This includes two tests to cover the expected behavior:

TestPlan_varsUnset has been updated so it will panic if it gets more than one request to input a variable
TestPlan_providerArgumentUnset covers #26035

Fixes #26035, #26027
@alisdair
Copy link
Contributor

alisdair commented Sep 2, 2020

I believe this issue was fixed in #26063, but GitHub didn't auto-close it. This is part of today's 0.13.2 release.

@alisdair alisdair closed this as completed Sep 2, 2020
@ghost
Copy link

ghost commented Oct 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.

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

Successfully merging a pull request may close this issue.

3 participants