Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unnecessary plan change when using interpolation syntax with TypeSet #19933

Closed
kilokahn opened this issue Jan 7, 2019 · 3 comments
Closed

Unnecessary plan change when using interpolation syntax with TypeSet #19933

kilokahn opened this issue Jan 7, 2019 · 3 comments

Comments

@kilokahn
Copy link

kilokahn commented Jan 7, 2019

Terraform Version

v0.11.7

Terraform Configuration Files

variable "tenancy_ocid" {}

variable "user_ocid" {}
variable "fingerprint" {}
variable "private_key_path" {}
variable "compartment_ocid" {}
variable "region" {}

provider "oci" {
  region           = "${var.region}"
  tenancy_ocid     = "${var.tenancy_ocid}"
  user_ocid        = "${var.user_ocid}"
  fingerprint      = "${var.fingerprint}"
  private_key_path = "${var.private_key_path}"
}

resource "oci_core_vcn" "test_vcn" {
  cidr_block     = "10.0.0.0/16"
  compartment_id = "${var.compartment_ocid}"

  display_name = "mubaig-vcn"
}

resource "oci_core_route_table" "test_route_table" {
  #Required
  compartment_id = "${var.compartment_ocid}"
  count          = 1

  route_rules {
    network_entity_id = "${lookup(data.oci_core_private_ips.test_private_ips.private_ips[0], "id")}"
    destination = "0.0.0.0/0"
  }

  vcn_id = "${oci_core_vcn.test_vcn.id}"

  display_name = "mubaig-route-table"
}

data "oci_identity_availability_domains" "ad" {
  compartment_id = "${var.tenancy_ocid}"
}

resource "oci_core_subnet" "test_subnet" {
  availability_domain = "${lookup(data.oci_identity_availability_domains.ad.availability_domains[0],"name")}"
  cidr_block          = "10.0.1.0/24"
  display_name        = "mubaig-subnet"
  compartment_id      = "${var.compartment_ocid}"
  vcn_id              = "${oci_core_vcn.test_vcn.id}"
}

resource "oci_core_instance" "test_instance" {
  depends_on = ["oci_core_subnet.test_subnet"]
  count      = 2

  availability_domain = "${lookup(data.oci_identity_availability_domains.ad.availability_domains[0], "name")}"
  compartment_id      = "${var.compartment_ocid}"
  display_name        = "mubaig-test-instance"
  shape               = "VM.Standard2.1"

  create_vnic_details {
    subnet_id              = "${oci_core_subnet.test_subnet.id}"
    skip_source_dest_check = "true"
  }

  source_details {
    #Required
    source_id   = "ocid1.image.oc1.phx.aaaaaaaaozjbzisykoybkppaiwviyfzusjzokq7jzwxi7nvwdiopk7ligoia"
    source_type = "image"
  }
}

data "oci_core_private_ips" "test_private_ips" {
  depends_on = ["oci_core_instance.test_instance"]
  subnet_id  = "${element(oci_core_subnet.test_subnet.*.id, 0)}"
  ip_address = "${element(oci_core_instance.test_instance.*.private_ip, 0)}"
}

Debug Output

https://gist.github.com/kilokahn/ece94de49fdd37f749cbc00d434bef72

Crash Output

N/A

Expected Behavior

There should have been no change in the plan

Actual Behavior

TF plan shows a spurious diff. When apply is run, it shows that no changes are actually applied.

tf plan

 ~ update in-place
 <= read (data resources)

Terraform will perform the following actions:

 <= data.oci_core_private_ips.test_private_ips
      id:                                        <computed>
      ip_address:                                "10.0.1.2"
      private_ips.#:                             <computed>
      subnet_id:                                 "ocid1.subnet.oc1.phx.aaaaaaaa4emr5usnz5r7qa77yrjshxqtmjtkaysmd5hvgx5zfglak6pf543q"

  ~ oci_core_route_table.test_route_table
      route_rules.1367368352.network_entity_id:  "ocid1.privateip.oc1.phx.abyhqljs7kppu6jgqxwxovissfxzmnzvpbq7ubxd53tp74gfmmndcvyab3la" => ""
      route_rules.~2933718002.cidr_block:        "" => <computed>
      route_rules.~2933718002.destination:       "" => "0.0.0.0/0"
      route_rules.~2933718002.destination_type:  "" => <computed>
      route_rules.~2933718002.network_entity_id: "" => "${lookup(data.oci_core_private_ips.test_private_ips.private_ips[0], \"id\")}"

Plan: 0 to add, 1 to change, 0 to destroy.

tf apply


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

Steps to Reproduce

  1. terraform init
  2. terraform plan
  3. terraform apply
  4. terraform plan # this should be empty, but it isn't
  5. terraform apply # this shows that there is no change

Additional Context

The oci_route_table (https://github.com/terraform-providers/terraform-provider-oci/blob/master/oci/core_route_table_resource.go#L33) has an attribute for route_rules which is a TypeSet and it seems to the underlying reason for the problem.
The custom hash function that we define is getting the non-interpolated string in these cases (like ${lookup(data.oci_core_private_ips.test_private_ips.private_ips[0], "id")} rather than the actual value from the state). With such a literal string, it seems impossible for the provider code to correctly discern the correct hash value to be used. In general, passing a non-interpolated value to the hashing function (or any other provider overridden code) should be avoided by terraform, right?

References

There was a similar bug that was logged earlier - #2879 - which was mitigated by creating a new resource for the nested entry - which may not make sense in every scenario.

@apparentlymart
Copy link
Contributor

Hi @kilokahn! Sorry for this confusing behavior.

It looks like you've found issue #18600 here. If you remove depends_on from the data "oci_core_private_ips" "test_private_ips" block the problem should go away. That depends_on argument is redundant anyway, since there's already a reference to oci_core_instance.test_instance in the ip_address argument.

Since this is the same as #18600, I'm going to close it out. Thanks for reporting this!

@kilokahn
Copy link
Author

kilokahn commented Jan 8, 2019

I can confirm that this works for me. Thanks for the quick response!

@ghost
Copy link

ghost commented Mar 30, 2020

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.

@ghost ghost locked and limited conversation to collaborators Mar 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants