Infrastructure objects continually update with no changes

[pgsmith123]

I am using vRA 8.4.1, terraform 1.0.1, and the vRA provider 0.3.8.

I have configured a vSphere cloud account, two zones, and an image mapping with four templates. The initial apply builds all the objects correctly. When running a secondary plan or apply terraform wants to update all the objects even though no changes have been made.

cloud account

# vra_cloud_account_vsphere.vmconsole will be updated in-place
  ~ resource "vra_cloud_account_vsphere" "vmconsole" {
        id                           = "d6fb8984-0e2c-4045-a7d0-59ea6ed674ce"
        name                         = "vmconsole.hosting.it.ufl.edu"
      ~ regions                      = [
          - "Datacenter:datacenter-26",
            "Datacenter:datacenter-21",
          + "Datacenter:datacenter-26",
        ]
        # (12 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

zone

# vra_zone.vmconsole_az1 will be updated in-place
  ~ resource "vra_zone" "vmconsole_az1" {
        id                 = "7713be6b-7521-4655-9c64-bd433c6f34f5"
        name               = "vmconsole_az1"
      ~ region_id          = "b09a7af0-b52c-4bcf-9623-0aa4c40f6998" -> (known after apply)
        # (8 unchanged attributes hidden)

        # (4 unchanged blocks hidden)
    }

image mapping

# vra_image_profile.az1 will be updated in-place
  ~ resource "vra_image_profile" "az1" {
        id                 = "1766c32c-f4d8-4516-acd9-19ab85d54270-b09a7af0-b52c-4bcf-9623-0aa4c40f6998"
        name               = "AZ1"
      ~ region_id          = "b09a7af0-b52c-4bcf-9623-0aa4c40f6998" -> (known after apply)
        # (2 unchanged attributes hidden)

      - image_mapping {
          - description = "31-07-2020" -> null
          - external_id = "523cdc5a-3235-4c10-a9d2-b5c00e739e63" -> null
          - image_id    = "cd2a93738e99ffe6c7f08182821fc4e02aea4386" -> null
          - image_name  = "Hosting / Server 2019 Standard Core" -> null
          - name        = "Hosting / Server 2019 Standard Core" -> null
          - os_family   = "WINDOWS" -> null
          - private     = false -> null
        }
     + image_mapping {
          + description        = (known after apply)
          + external_id        = (known after apply)
          + external_region_id = (known after apply)
          + image_id           = (known after apply)
          + name               = "Hosting / Server 2019 Standard Core"
          + organization       = (known after apply)
          + os_family          = (known after apply)
          + owner              = (known after apply)
          + private            = (known after apply)
        }

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

Running an apply completes successfully and says that it updates the cloud account and the image mappings.

data.vra_image.windows_server_2016_core: Reading... [id=7990823954822617dfdc06959c8b6f0cfad83f4a]
data.vra_image.windows_server_2019_core: Reading... [id=cd2a93738e99ffe6c7f08182821fc4e02aea4386]
data.vra_image.windows_server_2019_gui: Reading... [id=9cbddbf5c07eabbeb0b15c5fcda975c65a4fd669]
data.vra_image.windows_server_2016_gui: Reading... [id=91d33d79ddedd9c13f0eb852bdad15fd10c5ffec]
vra_cloud_account_vsphere.vmconsole: Modifying... [id=d6fb8984-0e2c-4045-a7d0-59ea6ed674ce]
data.vra_image.windows_server_2016_core: Read complete after 0s [id=7990823954822617dfdc06959c8b6f0cfad83f4a]
data.vra_image.windows_server_2019_core: Read complete after 0s [id=cd2a93738e99ffe6c7f08182821fc4e02aea4386]
data.vra_image.windows_server_2019_gui: Read complete after 0s [id=9cbddbf5c07eabbeb0b15c5fcda975c65a4fd669]
data.vra_image.windows_server_2016_gui: Read complete after 0s [id=91d33d79ddedd9c13f0eb852bdad15fd10c5ffec]
vra_cloud_account_vsphere.vmconsole: Still modifying... [id=d6fb8984-0e2c-4045-a7d0-59ea6ed674ce, 10s elapsed]
vra_cloud_account_vsphere.vmconsole: Modifications complete after 16s [id=d6fb8984-0e2c-4045-a7d0-59ea6ed674ce]
data.vra_region.vmconsole_region_az2: Reading... [id=4aaf391f-f818-4d94-92cd-128cb9b00907]
data.vra_region.vmconsole_region_az1: Reading... [id=b09a7af0-b52c-4bcf-9623-0aa4c40f6998]
data.vra_region.vmconsole_region_az1: Read complete after 0s [id=b09a7af0-b52c-4bcf-9623-0aa4c40f6998]
data.vra_region.vmconsole_region_az2: Read complete after 0s [id=4aaf391f-f818-4d94-92cd-128cb9b00907]
vra_image_profile.az1: Modifying... [id=1766c32c-f4d8-4516-acd9-19ab85d54270-b09a7af0-b52c-4bcf-9623-0aa4c40f6998]
vra_image_profile.az1: Modifications complete after 0s [id=1766c32c-f4d8-4516-acd9-19ab85d54270-b09a7af0-b52c-4bcf-9623-0aa4c40f6998]

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

Nothing seems to be updated on the vRA side and everything continues working as expected.

It always wants to update the same items every time an apply or plan is executed.

This is the config for the cloud account and zones

#USE TO GET VSPHERE REGION IDS ON APPLY COMMAND OUTPUT
#data "vra_region_enumeration_vsphere" "vmconsole-regions" {
#  username                = var.vmconsole_username
#  password                = var.vmconsole_password
#  hostname                = var.vmconsole_name
#}

resource "vra_cloud_account_vsphere" "vmconsole" {
  name        = var.vmconsole_name
  description = var.vmconsole_name
  username    = var.vmconsole_username
  password    = var.vmconsole_password
  hostname    = var.vmconsole_name
  #regions     = data.vra_region_enumeration_vsphere.vmconsole-regions.regions
  regions     = [var.vmconsole_az1_id,var.vmconsole_az2_id]

  tags {
    key = "vCenter"
    value = "vmconsole"
  }
}

#wait 5 minutes after creating vsphere account to collect inventory

resource "time_sleep" "wait_5_minutes" {
  depends_on = [vra_cloud_account_vsphere.vmconsole]

  create_duration = "5m"
}

resource "null_resource" "next" {
  depends_on = [time_sleep.wait_5_minutes]
}

#create cloud zones

data "vra_region" "vmconsole_region_az1" {
  cloud_account_id = vra_cloud_account_vsphere.vmconsole.id
  region = var.vmconsole_az1_id
  depends_on = [
    null_resource.next
  ]
}

data "vra_region" "vmconsole_region_az2" {
  cloud_account_id = vra_cloud_account_vsphere.vmconsole.id
  region = var.vmconsole_az2_id
  depends_on = [
    null_resource.next
  ]
}

resource "vra_zone" "vmconsole_az1" {
  name        = "vmconsole_az1"
  description = "vmconsole_az1"
  region_id   = data.vra_region.vmconsole_region_az1.id

 tags_to_match {
    key = "Cluster"
    value = "DRS01"
  }

  tags {
    key   = "vCenter"
    value = "vmconsole"
  }

  tags {
    key   = "Availability Zone"
    value = "AZ1"
  }

  tags {
    key = "Cluster"
    value = "DRS01"
  }

  depends_on = [
    null_resource.next
  ]
}

resource "vra_zone" "vmconsole_az2" {
  name        = "vmconsole_az2"
  description = "vmconsole_az2"
  region_id   = data.vra_region.vmconsole_region_az2.id

  tags_to_match {
    key = "Cluster"
    value = "DRS01"
  }

  tags {
    key   = "vCenter"
    value = "vmconsole"
  }

  tags {
    key   = "Availability Zone"
    value = "AZ2"
  }

  tags {
    key = "Cluster"
    value = "DRS01"
  }

  depends_on = [
    null_resource.next
  ]
}

[VickyWinner]

I see the similar issue as @pgsmith123.

[rnelson0]

I don't know much about writing Go, but I've seen that a TypeList is used when the order matters, but a TypeSet can be used when the order has no impact on behavior. datasource_cloud_account_vmc.go uses a TypeList and perhaps changing to TypeSet would suffice, since it appears (to me as a user) that the order shouldn't affect behavior.

[rnelson0]

If that's correct (and again, I do not know go very well) then perhaps the fix is as simple as replacing L55-61 with

            "regions": {
                Type:     schema.TypeSet,
                Computed: true,
                Elem: &schema.Schema{
                    Type: schema.TypeString,
                },
            },

I don't think the tests need updated since the Type is not specified in it.

[frodenas]

@rnelson0 You're right, if the order does not matter, we should be using a TypeSet. I've submitted PR #411 to address this.

But the above PR will not fix all the resources, there are some of them (specifically vra_flavor_profile and vra_image_profile) that need some extra work. The challenge here is that there is actually no way of setting a stable identifier for Sets, so for those objects where vRA adds some extra parameters (like the previously mentioned one), every time you perform an apply operation, Terraform is going to detect that there is a change (see this discussion for more details). The (ultimate) fix most likely will introduce some breaking changes, so we need to properly evaluate how we are going to introduce them.

[rnelson0]

@frodenas Awesome, thank you for that PR! I’m looking forward to testing this out soon!

[rnelson0]

@frodenas FYI We're on 0.5.0+ and no longer seeing this issue. Can't speak for @pgsmith123 of course but maybe this addressed their issue, too.

[tenthirtyam]

What about you @VickyWinner?

Ryan Johnson Senior Staff Solutions Architect | Product Engineering @ VMware, Inc.

[BergCyrill]

We are still seeing the issue using the vra_image_profile resource having multiple image_mappings. As far as I can see, the resource was not touched with PR #411.

We use the latest version of the vra_provider 0.5.1 from the hashicorp registry.

[whochradel]

I am seeing the issue once again with 0.7.0 from the hashicorp registry for vra_image_profile. I believe that 0.7.0 switched to using image_id where as 0.6.0 was using image_name. I was able to successfully see no changes with 0.6.0 but now see changes each time I run terraform with 0.7.0

[zimbeo]

I too am still having this problem with the vra_image_profile resource. We're using 0.8.6 from the HashiCorp registry.