Hey there,
I was excited to see import in the changelog for 0.7 so I built Terraform from dce1754. I attempted a simple import of an existing AWS instance:
terraform import aws_instance.foo i-12345678
I have variables.tf and terraform.tfvars set up to configure an aws provider but the import command doesn't appear to load them. I scanned the docs at https://github.com/hashicorp/terraform/tree/master/website/source/docs/import and there's no mention of how else the provider would be expected to be configured. It appears environment variables work, though AWS_PROFILE doesn't appear to load region configuration while it does load access and secret key.
A quick search for an existing issue didn't reveal anything.
Terraform v0.7.0-dev (dce175459a9b0bc1f42b1b0f919aae294a73a138)
variable "access_key" {}
variable "secret_key" {}
variable "region" { default = "us-west-2" }
provider "aws" {
access_key = "${var.access_key}"
secret_key = "${var.secret_key}"
region = "${var.region}"
}
AWS provider is configured from tfvars and resource is successfully imported.
Import fails with:
...
* No valid credential sources found for AWS Provider.
...
As noted above this can be worked around by using env vars.
terraform import aws_instance.foo i-12345678I can confirm this bug.
I can confirm as well.
I can confirm that this is still an issue on 0.7.3.
and 0.7.4
and 0.7.5 too
0.7.7, still there
+1 Same problem here ...
same for me
Terraform v0.7.7
PR open to fix this. This was a documented limitation of import, but we've removed it for 0.8.
Until 0.8 is there a way I can pass the profile along with the import command, or set a profile env variable? Or is the only way to set the AWS key environment variables?
@csabatini you should be able to use AWS_PROFILE and AWS_DEFAULT_REGION env variables to work around this issue.
That worked! Thanks
Hi guys, I have hit this bug when I was building my jenkins pipeline, I'm curious to ask what others are doing to avoid putting a file with the credentials on the jenkins server :(
Thank you!
I just hit this with Terraform v0.8.2
Error importing: 1 error(s) occurred:
* 1:3: unknown variable accessed: var.aws_access_key in:
${var.aws_access_key}
terraform plan in same directory works
still a problem in
› terraform --version
Terraform v0.8.5
Error importing: 1 error(s) occurred:
* 1:3: unknown variable accessed: var.aws_access_key in:
${var.aws_access_key}
I don't understand how #9809 was supposed to fix this
```system in qa-2/ on dmb-master-qa-2
› terraform import module.site.aws_db_instance.default lh-wordpress-qa-2
Error importing: 1 error(s) occurred:
${var.aws_access_key}
system in qa-2/ on dmb-master-qa-2
› terraform import -config="" module.site.aws_db_instance.default lh-wordpress-qa-2
provider.aws.region
The region where AWS operations will take place. Examples
are us-east-1, us-west-2, etc.
Default: us-east-1
Enter a value: ^C
Error importing: 1 error(s) occurred:
system in qa-2/ on dmb-master-qa-2
› terraform import -config=. module.site.aws_db_instance.default lh-wordpress-qa-2
Error importing: 1 error(s) occurred:
${var.aws_access_key}
system in qa-2/ on dmb-master-qa-2
› terraform import -config="terraform.tfvars" module.site.aws_db_instance.default lh-wordpress-qa-2
Error loading config: configuration path must be a directory: terraform.tfvars```
Hey @donnoman, we mark an issue as fixed when we have a regression case that mimics (and typically is based on) the opening issue that is resolved. In this case, we resolved the issue we were able to test. This doesn't mean that its fixed in every case (though we like to think so), just that we fixed every known case. :) You bringing up more cases helps us find more edge cases to test for and therefore fix.
If you (or anyone else still getting this could) please open a new issue with configuration to reproduce this then we'll gladly resolve this!
@donnoman while looking how to get around this I found that -var-file flag just works here:
terraform import -var-file=variables.tfvars aws_db_instance.foo db-bar
Got it from here: #10768
What I did, as a complete hack / workaround, was to move all .tf sources outside the folder, then run the import command, then move them back.
Admittedly, i was only importing a single bucket / single IAM user / etc., in a new env, so not sure if this is a workaround others can use too...
I had the very same issue. In our case it was because we use variables to configure AWS provider to parametrise the target AWS account. e.g:
provider "aws" {
region = "${var.aws_region}"
assume_role {
role_arn = "arn:aws:iam::${var.sub_account_id}:role/admin"
session_name = "terraform-sub-account-${var.sub_account_id}"
}
}
That variable var.sub_account_id is being computed using interpolation from a table of accounts:
module "picasso-sub-account-credstash-mmgdev" {
source = "./modules/sub-account-credstash"
credstash_alias = "credstash-picasso"
sub_account_id = "${lookup(var.aws_accounts, "mmgdev")}"
}
Whenever we run import, that completely blows up with the errors like:
arn:aws:iam::${var.sub_account_id}:role/admin
* module.architecture-sub-account-devteam-access-xtractdev.provider.aws: 1:16: unknown variable accessed: var.sub_account_id in:
passing -vars-file did not solve the issue.
As commented by @gsaslis https://github.com/hashicorp/terraform/issues/7774#issuecomment-282119699, the solution was create a temporary terraform directory with only the resources to import and without variable interpolation in the resource. Then I copied manually the terraform state content.
More or less:
Create a new terraform dir with only the resources to import and submodules where the provider does not use variables. Presuming you keep the config in infra:
mkdir -p infra.tmp/modules
cp -Ra infra/modules/sub-account-credstash/ infra.tmp/modules/sub-account-credstash.dev
sed -i 's/${var.sub_account_id}/11111111111/' infra.tmp/modules/sub-account-credstash.dev/main.tf
cp -Ra infra/modules/sub-account-credstash/ infra.tmp/modules/sub-account-credstash.prod
sed -i 's/${var.sub_account_id}/22222222222/' infra.tmp/modules/sub-account-credstash.prod/main.tf
the main config file, must point to the corresponding submodules
cp -Ra infra/devteam-picasso.tf infra.tmp
vim infra.tmp/devteam-picasso.tf # change to directory of the modules
Import the resources:
terraform get
terraform import module.picasso-sub-account-credstash-mmgdev.aws_kms_key.credstash 0f5ee3af-3975-47d6-af75-2b7632af4167 # note, fake uuid
terraform import module.picasso-sub-account-credstash-mmgdev.aws_kms_alias.credstash alias/credstash-picasso
terraform import module.picasso-sub-account-credstash-mmgdev.aws_dynamodb_table.credstash credstash-picasso
terraform import module.picasso-sub-account-credstash-mmgprod.aws_kms_key.credstash e34aaed7-47a9-4750-95c7-23a5b5c99aac # note, fake uuid
./run-terraform.tmp.sh import module.picasso-sub-account-credstash-mmgprod.aws_kms_alias.credstash alias/credstash-picasso
./run-terraform.tmp.sh import module.picasso-sub-account-credstash-mmgprod.aws_dynamodb_table.credstash credstash-picasso
terraform.tfstate. Manually copy the content into the old .tfstate (note, in our case we used S3+dynamodb, which required download the file, update it, upload, and update the MD5 in dynamodb)Same for me...
-var-file=terraform.tfvars doesn't work either
Terraform v0.10.0
Same for me as well, this bug is making my life very difficult right now!
terraform v0.10.3
Setting AWS_DEFAULT_REGION etc as per previous comment does not help either.
@mitchellh @Preston4tw - This is still a bug and needs to be re-opened ASAP.
I'm using the terraform v0.10.4 and its happens too
I'm using the terraform v0.10.5 and its happens too
edit: this seems to fix it for those still looking https://github.com/hashicorp/terraform/issues/13018#issuecomment-291547654
Terraform 0.10.8 here... still, the same issue but in my case it happens with terraform plan
I have encountered this in Terraform 0.11.3.
And terraform v0.11.8
And terraform v0.12.12
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.
Most helpful comment
I just hit this with Terraform v0.8.2
terraform plan in same directory works