Terraform: Terraform doesn't plan or apply nested module resources when using target on parent module

Created on 25 Mar 2016  ยท  7Comments  ยท  Source: hashicorp/terraform

Doing terraform plan -target module.NAME on a target module that uses other modules does not show the underlying resources that will be created. Similarly, running terraform apply -target module.NAME does not create resources from the nested modules. However, running plain terraform apply will create them.

modules/module1/main.tf

provider "aws" {
  region = "us-east-1"
}

resource "aws_elb" "web" {
  name = "terraform-example-elb"

  # The same availability zone as our instances
  availability_zones = ["${aws_instance.web.*.availability_zone}"]

  listener {
    instance_port = 80
    instance_protocol = "http"
    lb_port = 80
    lb_protocol = "http"
  }

  instances = ["${aws_instance.web.*.id}"]
}


resource "aws_instance" "web" {
  instance_type = "m1.small"
  ami = "ami-de7ab6b6"

  count = 1
}

modules/module2/main.tf

module "module1" {
  source = "../module1"
}

main.tf

module "module2" {
  source = "./modules/module2"
}

Terraform plan:

$ terraform plan -target module.module2
Refreshing Terraform state prior to plan...


No changes. Infrastructure is up-to-date. This means that Terraform
could not detect any differences between your configuration and
the real physical resources that exist. As a result, Terraform
doesn't need to do anything.

Terraform apply:

$ terraform apply -target module.module2

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

$ terraform apply                      
module.module2.module1.aws_instance.web: Creating...
  ami:                      "" => "ami-de7ab6b6"
  availability_zone:        "" => "<computed>"
  ebs_block_device.#:       "" => "<computed>"
  ephemeral_block_device.#: "" => "<computed>"
  instance_state:           "" => "<computed>"
  instance_type:            "" => "m1.small"
  key_name:                 "" => "<computed>"
  placement_group:          "" => "<computed>"
  private_dns:              "" => "<computed>"
  private_ip:               "" => "<computed>"
  public_dns:               "" => "<computed>"
  public_ip:                "" => "<computed>"
  root_block_device.#:      "" => "<computed>"
  security_groups.#:        "" => "<computed>"
  source_dest_check:        "" => "1"
  subnet_id:                "" => "<computed>"
  tenancy:                  "" => "<computed>"
  vpc_security_group_ids.#: "" => "<computed>"
module.module2.module1.aws_instance.web: Creation complete
module.module2.module1.aws_elb.web: Creating...
  availability_zones.#:                   "" => "1"
  availability_zones.3569565595:          "" => "us-east-1a"
  connection_draining:                    "" => "0"
  connection_draining_timeout:            "" => "300"
  dns_name:                               "" => "<computed>"
  health_check.#:                         "" => "<computed>"
  idle_timeout:                           "" => "60"
  instances.#:                            "" => "1"
  instances.3287691729:                   "" => "i-8fcde10c"
  internal:                               "" => "<computed>"
  listener.#:                             "" => "1"
  listener.3057123346.instance_port:      "" => "80"
  listener.3057123346.instance_protocol:  "" => "http"
  listener.3057123346.lb_port:            "" => "80"
  listener.3057123346.lb_protocol:        "" => "http"
  listener.3057123346.ssl_certificate_id: "" => ""
  name:                                   "" => "terraform-example-elb"
  security_groups.#:                      "" => "<computed>"
  source_security_group:                  "" => "<computed>"
  source_security_group_id:               "" => "<computed>"
  subnets.#:                              "" => "<computed>"
  zone_id:                                "" => "<computed>"
module.module2.module1.aws_elb.web: Creation complete

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

The state of your infrastructure has been saved to the path
below. This state is required to modify and destroy your
infrastructure, so keep it safe. To inspect the complete state
use the `terraform show` command.

State path: terraform.tfstate
bug core

Most helpful comment

+1
This really hurts our workflow

All 7 comments

+1

+1
This really hurts our workflow

+1
Same-same here with AzureRM provider.
Also, not only apply but destroy does see the modules at all as following:

$ terraform plan -target module.module2
Refreshing Terraform state prior to plan...

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

We did most of the things via modules, so such an issue makes terrafrom pretty useless.
Is there any workaround or suggestion on how to overcome that?

@radeksimko, would you guys please comment on this one?

I just refactored a whole Terraform project without checking whether this works and sadly it doesn't :( Would you please add a comment if you plan to solve this in the (near) future?

Dup #5190, this is a bug, earlier version there.

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ronnix picture ronnix  ยท  3Comments

rjinski picture rjinski  ยท  3Comments

shanmugakarna picture shanmugakarna  ยท  3Comments

rjinski picture rjinski  ยท  3Comments

franklinwise picture franklinwise  ยท  3Comments