heroku_space and heroku_space_peering_info cause consistent peering replacement

[mjuarez]

This may be more of a usage clarification, or a deficiency of how the provider is implemented. I'd like to create my heroku_space from scratch and peer into my VPC both which are managed in the same Terraform.

In order to create a peering connection, I need to refer to the heroku_space_peering_info. Without the space created first, the data resource will fail. I added an explicit depends_on in order for heroku_space to be created first before I can get the peering info.

However, on subsequent runs, the depends_on in heroku_space_peering_info will force the peering connection to be consistently replaced. If I remove the explicit depends_on after the initial run, subsequent runs work correctly.

Terraform Version

0.12.10

Heroku Provider Version

2.2.1

Affected Resource(s)

Please list the resources as a list, for example:

• resource.heroku_space
• data.heroku_space_peering_info
• aws_vpc_peering_connection.heroku

Terraform Configuration Files

resource "heroku_space" "space" {
  name         = "foo-${var.environment}"
  organization = "${var.heroku_organization}"

  cidr = "${var.heroku_cidr}"

  region = "virginia"
}

data "heroku_space_peering_info" "space" {
  name = "${heroku_space.space.name}"
  depends_on = ["heroku_space.space"]
}

resource "aws_vpc_peering_connection" "heroku" {
  peer_owner_id = "${data.heroku_space_peering_info.space.aws_account_id}"
  peer_vpc_id   = "${data.heroku_space_peering_info.space.vpc_id}"
  vpc_id        = "${module.vpc.vpc_id}"
}

resource "aws_vpc_peering_connection_options" "heroku" {
  vpc_peering_connection_id = "${aws_vpc_peering_connection.heroku.id}"

  accepter {
    allow_remote_vpc_dns_resolution = true
  }

  requester {
    allow_remote_vpc_dns_resolution = true
  }
}

resource "heroku_space_peering_connection_accepter" "heroku" {
  space                     = "${heroku_space.space.name}"
  vpc_peering_connection_id = "${aws_vpc_peering_connection.heroku.id}"
  depends_on                = ["aws_vpc_peering_connection.heroku"]
}

resource "aws_route" "heroku" {
  count                     = "${length(concat(module.vpc.public_route_table_ids, module.vpc.private_route_table_ids))}"
  route_table_id            = "${concat(module.vpc.public_route_table_ids, module.vpc.private_route_table_ids)[count.index]}"
  destination_cidr_block    = "${heroku_space.space.cidr}"
  vpc_peering_connection_id = "${aws_vpc_peering_connection.heroku.id}"
  depends_on                = ["heroku_space_peering_connection_accepter.heroku"]
}

Expected Behavior

I can create a space from scratch, retrieve peering information, and can setup a peering connection from AWS.

Actual Behavior

The peering connection needs to be replaced on every subsequent run.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform plan with HCL from above.

[mars]

Hi @mjuarez 😄

This issue is a documented limitation of Terraform Data Sources as dependencies.

The configuration will never converge.

For a dev environment this may be fine, but for production you need stability in the config.

One way to work around it is to use an input variable to set the identity of the resource once it’s created, instead of relying on dynamic data queries.

Maybe there’s an issue open on Terraform, or some other way to give them feedback, since they literally say not to do this in their docs 😕

[mjuarez]

With this obviously frowned upon, would it make sense for aws_account_id and vpc_id to be exposed through heroku_space resource instead of having an independent data resource?

If I have to create a workaround or not use best practices, I'm wondering if this is a flaw in how the provider is implemented and not Terraform itself.

[mars]

That’s an interesting idea @mjuarez , to expose those attributes directly on the Space resource. If we can get that data in a data source, then we should be able to get it as part of the resource’s create method.

Call it what you want, but thank you for helping to brainstorm a solution instead of just dumping the problem here.

I will have a bit more capacity to address in a few weeks. Feel free to open PR to propose the actual revision.