Variable interpolation bug when using terraform plan -target=module.XXXX

panmanphil commented 7 years ago

We have hit what we believe to be a bug with the -target option to terraform plan. I've put a sample the shows the problem at https://github.com/panmanphil/terraform-module-target-bug

The essence of the problem is that if you have a multiple module configuration, and want to plan and apply a subset to more properly layer the deployment, it fails because modules you have not targeted that also have a provider section, generate an error if they use variables.

terraform plan -target=module.cluster -var "aws_profile=yourvalidprofie" -var "aws_region=us-east-1" -var "env_name=dev"

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 running plan: 1 error(s) occurred:

* 1:3: unknown variable accessed: var.aws_profile in:

${var.aws_profile}

Terraform Version

Run terraform -v to show the version. If you are not running the latest version of Terraform, please upgrade because your issue may have already been fixed.

Terraform v0.8.6

Affected Resource(s)

Not specific to any resource

Terraform Configuration Files

https://github.com/panmanphil/terraform-module-target-bug

Expected Behavior

The module listed in the -target option should have been planned with any dependencies

Actual Behavior

Error message about a missing variable. This is only true for variables used in the provider block of modules not targeted:

provider aws {
  profile = "${var.aws_profile}"
  region = "${var.aws_region}"
}

Steps to Reproduce

Please list the steps required to reproduce the issue, for example: shown in the description above

Important Factoids

this is an aws stack. In my two module example, using the target as show, some setup for an ecs cluster, the other module, and ecs task and service, is not a dependency but it's provider block causes the problem. If I put valid values in that task module's provider sections, it works as expected, even though the same variables are used elsewhere in the module.

If I target the task, because it depends on the cluster, the error does not occur and both the task and cluster are in the plan.

apparentlymart commented 7 years ago

Hi @panmanphil! Sorry for the issue here.

I think this is the same problem as #10911, which was just fixed in the 0.8.7 release. Could you give this a try on 0.8.7 to confirm whether it is indeed the same issue and fixed?

panmanphil commented 7 years ago

Tried it, and unfortunately, no change, the error is still there

terraform plan -target=module.cluster -var "aws_profile=myprofile" -var "aws_region=us-east-1" -var "env_name=dev"
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 running plan: 1 error(s) occurred:

* 1:3: unknown variable accessed: var.aws_profile in:

${var.aws_profile}
PhilipNelsonMacbook:tf-target-bug philipnelson$ terraform -v
Terraform v0.8.7

panmanphil commented 7 years ago

I updated the issue as well, but with 0.8.7 the issue remains. dang!

On Thu, Feb 16, 2017 at 10:39 AM, Martin Atkins notifications@github.com wrote:

Hi @panmanphil https://github.com/panmanphil! Sorry for the issue here.

I think this is the same problem as #10911 https://github.com/hashicorp/terraform/issues/10911, which was just fixed in the 0.8.7 release. Could you give this a try on 0.8.7 to confirm whether it is indeed the same issue and fixed?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hashicorp/terraform/issues/12009#issuecomment-280384610, or mute the thread https://github.com/notifications/unsubscribe-auth/ACG9Efu6j9F8c4rUUJOIfNEVyhmuW61dks5rdHvGgaJpZM4MDDYQ .

apparentlymart commented 7 years ago

Thanks for trying it, @panmanphil. Probably a new issue with similar symptoms then, so I'll leave this here to track it.

ashald commented 7 years ago

Coming here from #12024 - ran into the same issue earlier today. I'm wondering whether it ever worked (in the sense that maybe we can try some older version to figure out when it became broken).