opc_compute_orchestrated_instance with defined sec_lists forces new resource on each apply

[riselka]

Terraform Version

amaslows@AMASLOWS-US MINGW64 /D/TERRAFORM/tf-sonpopsch1 $ terraform -v Terraform v0.11.7

• provider.opc v1.1.2

Affected Resource(s)

opc_compute_orchestrated_instance

Terraform Configuration Files

 resource "opc_compute_security_list" "sec_list1" {
  name                 = "${var.basename}-default-seclist"
  policy               = "deny"
  outbound_cidr_policy = "permit"
}

resource "opc_compute_orchestrated_instance" "mvm_01" {
  name          = "${var.basename}"
  desired_state = "active"

  instance {
    name     = "${var.basename}"
    shape    = "oc4"
    ssh_keys = ["${opc_compute_ssh_key.id_rsa.name}"]

    storage {
      volume = "${opc_compute_storage_volume.storage.name}"
      index  = 1
    }

    storage {
      volume = "${opc_compute_storage_volume.u02.name}"
      index  = 2
    }

    boot_order = [1]

    networking_info {
      index          = 0
      shared_network = "true"
      nat            = ["${opc_compute_ip_reservation.ipreservation1.name}"]    
      sec_lists      = [ "${opc_compute_security_list.sec_list1.name}" ]
    }
  }
}

Expected Behavior

on 2nd 'terraform apply' with not change, terraform should not try and change the instance and force a recreate

Actual Behavior

instance.0.networking_info.0.sec_lists.0: "/Compute-603703907/username@oracle.com/sonpopsch1-testterraform-default-seclist" => "sonpopsch1-testterraform-default-seclist" (forces new resource)

Steps to Reproduce

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

1. terraform apply
2. terraform apply

Important Factoids

on initial apply which creates the orchestrated instance: instance.0.networking_info.0.sec_lists.0: "" => "sonpopsch1-testterraform-default-seclist"

then on the second apply with no change to .tf, it appears to have changed the details and shows: instance.0.networking_info.0.sec_lists.0: "/Compute-603703907/username@oracle.com/sonpopsch1-testterraform-default-seclist" => "sonpopsch1-testterraform-default-seclist" (forces new resource)

This same configuration does not cause a rebuild when using a normal compute instance resource like:

resource "opc_compute_instance" "instance_01" {
  name     = "${var.basename}"
  shape    = "oc4"
  ssh_keys = ["${opc_compute_ssh_key.id_rsa.name}"]

  storage {
    volume = "${opc_compute_storage_volume.storage.name}"
    index  = 1
  }

  storage {
    volume = "${opc_compute_storage_volume.u02.name}"
    index  = 2
  }

  boot_order = [1]

  networking_info {
    index          = 0
    shared_network = "true"
    nat            = ["${opc_compute_ip_reservation.ipreservation1.name}"]    
    sec_lists      = ["${opc_compute_security_list.sec_list1.name}"]
  }
}

References

based most of this off: https://orahub.oraclecorp.com/pts-cloud-dev/terraform-examples/blob/master/opc/instance-with-ssh/main.tf

but that is for normal compute, not orchestrated,

I will try workaround suggested in the meantime: Stephen Cross [5 hours ago] @Anthony Maslowski this looks like a bug, can you open an Issue at https://github.com/terraform-providers/terraform-provider-opc to track it. (edited) Stephen Cross [5 hours ago] meanwhile a workaround would be to try using the fully qualified name in the config - try setting sec_lists = [ "/Compute-${var.domain}/${var.user}/${opc_compute_security_list.sec_list1.name}" ]

[riselka]

suggested workaround, looks to work fine: sec_lists = [ "/Compute-${var.domain}/${var.user}/${opc_compute_security_list.sec_list1.name}" ]

@scross01

[scross01]

@amaslows this issue is resolved in v1.2.0 of the provider so you can use just ${opc_compute_security_list.sec_list1.name}" for the sec_list. The workaround also continues to work to this should not affect any existing deployed configuration.