Error: Unassigned variable
Meemaw opened this issue · 19 comments
Hi, I'm trying to run atlantis on AWS Fragate through https://github.com/terraform-aws-modules/terraform-aws-atlantis.
I've set up everything but am getting a wierd error. I am fairly sure that the variables are set through environment.
Crash Output
running "/usr/local/bin/terraform plan -input=false -refresh -no-color -out \"/home/atlantis/.atlantis/repos/meshwatch/infrastructure/terraform-gsuite/1/default/default.tfplan\"" in "/home/atlantis/.atlantis/repos/meshwatch/infrastructure/terraform-gsuite/1/default": exit status 1
Error: Unassigned variable
The input variable "access_key" has not been assigned a value. This is a bug
in Terraform; please report it in a GitHub issue.
Error: Unassigned variable
The input variable "secret_key" has not been assigned a value. This is a bug
in Terraform; please report it in a GitHub issue.
Error: Unassigned variable
The input variable "region" has not been assigned a value. This is a bug in
Terraform; please report it in a GitHub issue.
I believe i was also seeing this issue after upgrading terraform to 0.12.
Here is the travis build where we began seeing the errors in our acceptance tests. https://travis-ci.org/nukosuke/terraform-provider-zendesk/jobs/537885423
Diff is here. nukosuke/terraform-provider-zendesk@c417e18...efe8126.
HI @Meemaw,
All variables require value, either provided via a default, the cli, a tfvars file, or interactively. If there's no value provided, and you are using -input=false, there is no way to set a value for the variable, and you will see the error shown.
@jbardin if you look at the build link above you can see that the environment variables being passed to terraform an I can confirm that this only occurs after upgrading to 0.12
While it's true that all variables do need to be assigned, this error is reporting that variable values are not being passed properly around inside Terraform Core itself. IIRC it arises when terraform.NewContext is called without a full complement of variables, because it expects that the frontend code in the command package is responsible for properly loading, validating, and preparing variables.
The message suggests that there's a bug in the variable-checking and/or variable-handling code in either the command package or in backend/local.
Hi @tamccall,
Sorry, I didn't see your addition here for some reason. The original error here looks like variables missing from the config or cli, while yours is coming from the plugin test fixture. I that may be more closely related to the issue about TF_VAR_ variables used in the provider tests here: #21162
@jbardin Ill add my links over to that ticket as well since i am passing the variables to terraform via environment variables.
I came here through google, I am having the same problem. I have a key I've generated for an application which has all sorts of fun chars like ( + ] and so on and terraform has been throwing this error. I'm not sure if the contents of the var are related to this problem but it sounds like something is choking along those lines as TF is fine with the rest of my vars.
EDIT: Should probably mention I am using 0.12.5
EDIT EDIT: This seems to be fixed by using TF_VAR_ in the gitlab pipeline definition, so it's something related to terraform reading the variable from the environment rather than TF_VAR_ which tells our gitlab to put it on the command line.
I do not know if it is related to this bug, but anyway, this is my case:
I have a variable defined as:
# var labels
variable "label_inputs" {
description = "List of label to be used in your module (e.g `name`, `namespace`, `environment`, `team` and `tags` [Tags e.g. `{BusinessUnit = 'XYZ'}`])"
type = object({
name = string
namespace = string
team = string
environment = string
delimiter = string
tags = map(string)
})
}
On my terraform.tfvars I am passing some values to my label_inputs like this:
region = "us-east-1"
label_inputs = {
name = "logs"
namespace = "test"
team = "SRE"
environment = "prod"
delimiter = "."
tags = {}
}
and I am trying to use those values in my main.tf, which is defined as:
module "label" {
source = "../aws/label/"
name = var.label_inputs.name
namespace = var.label_inputs.namespace
team = var.label_inputs.team
environment = var.label_inputs.environment
delimiter = var.label_inputs.delimiter
tags = var.label_inputs.tags
}
on that scenario when I run terraform plan the output is:
Terraform has been successfully initialized!
You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.
If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
Error: Unassigned variable
The input variable "label_inputs" has not been assigned a value. This is a bug
in Terraform; please report it in a GitHub issue.
Error: The command exited with status 1
Terraform version: 0.12.5
Any clue if is it related or should I convert it to a ticket?
We have the same issue with TF 0.12.6. Terraform ignores TF_VAR_whatever
I'm seeing this, too.
$ ls | grep vars
terraform.auto.tfvars
$ ./terraform plan
Running plan in the remote backend. Output will stream here. Pressing Ctrl-C
will stop streaming the logs, but will not stop the plan running remotely.
Preparing the remote plan...
To view this run in a browser, visit:
https://app.terraform.io/app/DoU-TFE/nathan-ptfe-demo/runs/run-zVESqbDinZDqyhpG
Waiting for the plan to start...
Terraform v0.12.6
Configuring remote state backend...
Initializing Terraform configuration...
2019/08/13 21:16:12 [DEBUG] Using modified User-Agent: Terraform/0.12.6 TFE/5abd315
Error: Unassigned variable
The input variable "aws_region" has not been assigned a value. This is a bug
in Terraform; please report it in a GitHub issue.
After I add the aws_region variable, and set it to us-west-2, I get this:
$ ./terraform plan
Running plan in the remote backend. Output will stream here. Pressing Ctrl-C
will stop streaming the logs, but will not stop the plan running remotely.
Preparing the remote plan...
To view this run in a browser, visit:
https://app.terraform.io/app/DoU-TFE/nathan-ptfe-demo/runs/run-VWoM6ZRmv6LJUQPe
Waiting for the plan to start...
Terraform v0.12.6
Configuring remote state backend...
Initializing Terraform configuration...
2019/08/13 21:19:36 [DEBUG] Using modified User-Agent: Terraform/0.12.6 TFE/5abd315
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.
Error: No valid credential sources found for AWS Provider.
Please see https://terraform.io/docs/providers/aws/index.html for more information on
providing credentials for the AWS Provider
on main.tf line 5, in provider "aws":
5: provider "aws" {
I started encountering this issue after the recent updates to the free tier on Terraform Cloud (post HashiConf 2019). When using the remote backend (tf cloud), my plan would fail as follows:
$ terraform plan
Running apply in the remote backend. Output will stream here. Pressing Ctrl-C
will cancel the remote apply if it's still pending. If the apply started it
will stop streaming the logs, but will not stop the apply running remotely.
Preparing the remote apply...
To view this run in a browser, visit:
https://app.terraform.io/app/<workspace>/<remote_state_id>/runs/run-<run-id>
Waiting for the plan to start...
Terraform v0.12.8
Configuring remote state backend...
Initializing Terraform configuration...
2019/09/12 15:51:46 [DEBUG] Using modified User-Agent: Terraform/0.12.8 TFC/4aeade9300
Error: Unassigned variable
The input variable "credentials_file_path" has not been assigned a value. This
is a bug in Terraform; please report it in a GitHub issue.
This was configuration code that had been working just fine prior to HashiConf 2019 (when all the changes to Terraform Cloud went GA), so after scratching my head I tried running an apply with the -var-file= argument to force it to see my terraform.tfvars file, where my variable values are defined. Then I saw this:
$ terraform plan -var-file=terraform.tfvars
Error: Run variables are currently not supported
The "remote" backend does not support setting run variables at this time.
Currently the only to way to pass variables to the remote backend is by
creating a '*.auto.tfvars' variables file. This file will automatically be
loaded by the "remote" backend when the workspace is configured to use
Terraform v0.10.0 or later.
Additionally you can also set variables on the workspace in the web UI:
https://app.terraform.io/app/<workspace>/<remote_state_id>/variables
I then changed my terraform.tfvars to be called terraform.auto.tfvars and the variable assignments were properly passed through, except for the ones I purposely left undefined (which I prefer to pass in through the CLI because they are specific to my GCP project context, so I can reuse the same code for different projects).
So after following the suggestion to set variables on the workspace in the web UI which got me past that problem, I'm now running in to an issue where I can no longer interpolate terraform.workspace in the same manner that i'd been using it before, in resource argument definitions:
$ terraform plan
Running apply in the remote backend. Output will stream here. Pressing Ctrl-C
will cancel the remote apply if it's still pending. If the apply started it
will stop streaming the logs, but will not stop the apply running remotely.
Preparing the remote apply...
To view this run in a browser, visit:
https://app.terraform.io/app/<workspace>/<remote_state_id>/runs/run-<run_id>
Waiting for the plan to start...
Terraform v0.12.8
Configuring remote state backend...
Initializing Terraform configuration...
2019/09/12 16:04:12 [DEBUG] Using modified User-Agent: Terraform/0.12.8 TFC/4aeade9300
Error: Invalid index
on compute.tf line 2, in locals:
2: hostname = "i${var.env_prefix[split("-", terraform.workspace)[1]]}-dgraph-test-cluster-"
|----------------
| terraform.workspace is "default"
The given key does not identify an element in this collection value.
For some reason it sees my workspace as default even though I have it set (and my workspace gets passed through properly in my backend config workspaces prefix...):
$ terraform workspace list
* workspace-staging
So there seem to be some pretty big changes to the remote backend post HashiConf 2019 that I'll need to work through. But the simple fix for most people in similar scenarios should be changing terraform.tfvars to terraform.auto.tfvars, or just setting them manually in the Terraform Cloud console. Hopefully this helps other people.
UPDATE
So I changed my execution mode in TF Cloud for this scope to run locally instead of remote, and 🎉🎉🎉! Fixed all my problems. These changes caught me off guard, so hopefully more people are paying better attention than I am to the HC2019 announcements.
Just keep in mind -- it seems if you’re using the new TF Cloud free tier and init a new remote backend, it will default the workspace to use remote instead of local (but prior existing workspaces are still set to local)
Just to chime in here, I ran into this error in Azure DevOps with ver. 0.12.8 when I was defining vars via:
TF_ENV-var- unassigned (still not working, no root cause found as of yet)-var 'variable=value'- assigned, but not defined
For the second case, it seems the docs (https://www.terraform.io/docs/commands/plan.html) might need a hand? I was able to get around this by defining them like so: -var variable='value'
Specific to Azure DevOps, if anyone's in the same boat: -var variable='$(VARIABLE)' is what solved it.
One of the issues I had in troubleshooting was color mode (which I love!) but which was messing a bit with the output:
A variable named "'variable" was assigned on the command line, but the
root module does not declare a variable of that name. To use this value, add a
"variable" block to the configuration.
Whereas once I started planning with -no-color added as an optional command line argument with the Microsoft-supplied Terraform plugin, all became clear:
Error: Value for undeclared variable
A variable named "'variable" was assigned on the command line, but the
root module does not declare a variable of that name. To use this value, add a
"variable" block to the configuration.
So there seem to be some pretty big changes to the
remotebackend post HashiConf 2019 that I'll need to work through. But the simple fix for most people in similar scenarios should be changingterraform.tfvarstoterraform.auto.tfvars, or just setting them manually in the Terraform Cloud console. Hopefully this helps other people.UPDATE
So I changed my execution mode in TF Cloud for this scope to run locally instead of remote, and 🎉🎉🎉! Fixed all my problems. These changes caught me off guard, so hopefully more people are paying better attention than I am to the HC2019 announcements.Just keep in mind -- it seems if you’re using the new TF Cloud free tier and
inita new remote backend, it will default the workspace to useremoteinstead oflocal(but prior existing workspaces are still set tolocal)
You, sir, just saved my day. Thanks (a whole lot of these) from Italy. Should you ever come near Genoa, ping me and you'll gain a beer.
EDIT for those with AWS CLI installed and configured: TFC workspaces' "remote plan execution" prevented the automatic scan of ~/.aws/config file that Terraform used to perform.
So, you have to explicitly define them inside .auto.tfvars file or switch to "local plan execution"
Hi all!
Reviewing the discussion here, it seems like there are several different issues all being reported together here.
We're treating this issue as being specifically about the error message covered in the original comment:
The input variable "example" has not been assigned a value. This is a bug
in Terraform; please report it in a GitHub issue.
If you are having other issues, please check if there's another issue for them already and if not please do feel free to open a new issue. For Terraform Cloud issues in particular it's important to separate them because they will likely be fixed in a different codebase (for Terraform Cloud) and so cannot be resolved along with the bug this issue is about, which is a Terraform CLI bug.
Thanks!
From my initial investigation here, I've learned that this error arises when input is disabled with -input=false or with the equivalent environment variable.
In that case, the processing doesn't happen in quite the right order right now: the initial validation of the variables happens prior to the input step, and it tolerates missing variables on the assumption that the input step will populate them. But when input is then disabled there's no final step to actually check that everything is correct, so it falls through into the internal safety check that is producing the "has not been assigned a value" error message.
Fixing this will require reordering these steps slightly so that the validation step can happen after the (optional) input step to make sure that everything has been populated one way or another before we pass the final set of variables in to the core part of Terraform.
New workspaces in Terraform Cloud defaulting to an Execution Mode of Remote cost several hours. Thanks for the pointer @jrsdav
Hi all!
Terraform 0.12.11 will contain a fix to properly catch this problem (required variables not set but -input=false so can't prompt) and return a proper error message for it:
Error: No value for required variable
The root module input variable "example" is not set, and has no default value. Use a -var
or -var-file command line argument to provide a value for this variable.
In the course of fixing that, we've also refactored how the variable value collection is implemented in the hope of allowing it to handle the presence and absence of required variables consistently in a single place, so that we shouldn't see differences anymore between variables set interactively vs. non-interactively, via the environment vs. CLI, etc.
If (after 0.12.11 is released and you've upgraded to it) you find that you are seeing the above message in cases where the variable in question is set, please do open a new issue for that and we can investigate what else is going on. There were a lot of different various problems reported in the comments above, so splitting each of them into a separate issue is a better way to give us room to discuss and debug each one separately and figure out what's going on, particularly since some of them seem to be Terraform Cloud issues rather than Terraform CLI issues and would thus require solutions in a different place.
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.