terraform-providers / terraform-provider-opc

Terraform Oracle Public Cloud provider
https://www.terraform.io/docs/providers/opc/
Mozilla Public License 2.0
29 stars 25 forks source link

fully qualified sshkeys not stored correctly #100

Open nshttpd opened 6 years ago

nshttpd commented 6 years ago

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.11.1
+ provider.opc v0.1.3

Affected Resource(s)

Please list the resources as a list, for example:

- opc_compute_instance

Terraform Configuration Files

resource "opc_compute_instance" "atl_test_1" {
  name = "atl-test-1"
  label = "test instance"
  shape = "oc3"
  image_list = "/oracle/public/OL_7.2_UEKR4_x86_64"

  ssh_keys = [
        "/Compute-XXX/first.last@company.co/key-zaphod",
        "/Compute-XXX/person.two@company.co/laptop-key",
        "/Compute-XXX/ford.prefect@company.co/here-for-beer"
    ]

  networking_info {
    index          = 0
    nat            = ["ippool:/oracle/public/ippool"]
    shared_network = true
    sec_lists      = ["${opc_compute_security_list.atl_test_1.name}"]
  }

  instance_attributes = <<JSON
{
  "owner": "person-new",
  "app": "test-box"
}  
JSON

}

Expected Behavior

When an instance is created with fully qualified SSH keys the tfstate file should store them as the fully qualified version and not just the key name. Upon an update to the infrastructure for other items the instance will want to destroyed and rebuilt because tfstate file doesn't match what's returned by REST API or what's in .tf file.

In the the tfstate file the keys are stored as :

                            "ssh_keys.#": "3",
                            "ssh_keys.0": "key-zaphod",
                            "ssh_keys.1": "laptop-key",
                            "ssh_keys.2": "here-for-beer",

When a plan is run :

      ssh_keys.#:                                  "3" => "3"
      ssh_keys.0:                                  "key-zaphod" => "/Compute-XXX/first.last@company.co/key-zaphod" (forces new resource)
      ssh_keys.1:                                  "laptop-key" => "/Compute-XXX/person.two@company.co/laptop-key" (forces new resource)
      ssh_keys.2:                                  "here-for-beer" => "/Compute-XXX/ford.prefect@company.co/here-for-beer" (forces new resource)

Looking at output for the instance from the REST API :

  "sshkeys": [
    "/Compute-XXX/first.last@company.co/key-zaphod",
    "/Compute-XXX/person.two@company.co/laptop-key",
    "/Compute-XXX/ford.prefect@company.co/here-for-beer"
  ],
  "resolvers": null,
  "account": "/Compute-XXX/default",

There is also some shenanigans around the order of the keys, but that's a trivial fix in the .tf file itself. Not saving the fully qualified in the tfstate is the bigger issue.

scross01 commented 6 years ago

Related to Issue #67