Cloning from the Image Server leads to a change after a second terraform apply

[mritzmann]

Describe the bug
My terraform file for a new server looks like this.

resource "nutanix_virtual_machine" "tf-bd787feb-6a5d-d9cd-24aa-9d743c5c5d2e" {
  name = "terraform20191023.test.example.com"
  cluster_uuid = "0004f701-5040-cf86-0000-000000002030"
  memory_size_mib = "2048"
  num_sockets = "1"
  guest_customization_cloud_init_user_data = "<data>"
  nic_list = [
    {
      subnet_uuid = "7352fa40-e2cb-4871-92a9-55eba44c8e10"
    }
  ]
  disk_list = [
    {
      data_source_reference = [{
        kind = "image"
        uuid = "6633046e-74fe-48cd-82ee-f78a42d3a0ac"
       }]
     }
  ]
}

1. I execute terraform apply: The server is successfully installed.
2. I execute terraform apply a second time: Terraform recognizes a change, although I have not changed anything in the file. Output looks like this:

$ terraform apply
nutanix_virtual_machine.tf-bd787feb-6a5d-d9cd-24aa-9d743c5c5d2e: Refreshing state... (ID: cd7e9b3d-1511-410f-8da4-eb7d200b82ce)

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  ~ nutanix_virtual_machine.tf-bd787feb-6a5d-d9cd-24aa-9d743c5c5d2e
      disk_list.#: "2" => "1"


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

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: 

Expected behavior
A terraform apply should not confuse a second terraform apply. It's unclear to me how to deal with this.

• Do I have to set something else in the tf-file from the beginning?
• Or do I have to adjust something between the first and second terraform apply?

I would like to prevent the second terraform apply, because we would like to generate and execute the terraform file automatically. It would be easiest if all this worked in one terraform apply.

Logs
I'll be happy to deliver more if necessary.

Versions (please complete the following information):

• OS: Debian 8.11
• Terraform: v0.11.14
• Nutanix Cluster (Prism Element / AOS): Version 5.10.6 LTS
• Nutanix Prism Central: 5.10.6
• Terraform provider version: v1.0.2, installed with provider "nutanix"

Additional context
We want to use Terraform in our automation. Therefore: Terraform files should be written and executed automatically in the future. This information has basically nothing to do with the bug report, but is important to understand why everything should work with only one terraform apply if possible.

[mritzmann]

resource "nutanix_virtual_machine" "tf-bd787feb-6a5d-d9cd-24aa-9d743c5c5d2e" {
  name = "terraform20191023.test.example.com"
  cluster_uuid = "0004f701-5040-cf86-0000-000000002030"
  memory_size_mib = "2048"
  num_sockets = "1"
  guest_customization_cloud_init_user_data = "<data>"
  nic_list = [
    {
      subnet_uuid = "7352fa40-e2cb-4871-92a9-55eba44c8e10"
    }
  ]
  disk_list = [
    {
      data_source_reference = [{
        kind = "image"
        uuid = "6633046e-74fe-48cd-82ee-f78a42d3a0ac"
       }]
     }
  ]
  lifecycle {
    ignore_changes = [
      "disk_list"
    ]
  }
}

Just found the meta-argument ignore_changes for the lifecycle block. Could be a possible solution for me. I will test it.

[mritzmann]

Works for me now. ignore_changes helps in my case, because I don't want to adapt the disk via terraform anyway.