google_alloydb_instance update on every run when values of availability_type and gce_zone is provided

[imrannayer]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
• Please do not leave +1 or me too comments, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.
• If an issue is assigned to the modular-magician user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned to hashibot, a community member has claimed the issue already.

Terraform Version

Terraform v1.3.6 on darwin_amd64

• provider registry.terraform.io/hashicorp/google v4.47.0
• provider registry.terraform.io/hashicorp/google-beta v4.47.0

  Affected Resource(s)

• google_alloydb_instance

Terraform Configuration Files

resource "google_alloydb_instance" "read_pool1" {
  provider          = google-beta
  cluster           = google_alloydb_cluster.default.name
  instance_id       = "alloydb-instance-read1"
  display_name      = "my-alloydb-instance-read1"
  instance_type     = "READ_POOL"
  availability_type = "ZONAL" #Possible values are AVAILABILITY_TYPE_UNSPECIFIED, ZONAL, and REGIONAL. Primary instance cannot be zonal
  gce_zone          = data.google_compute_zones.available_zones.names[0]
  machine_config {
    cpu_count = 4
  }
  read_pool_config {
    node_count = 1
  }
}

Debug Output

Panic Output

Expected Behavior

If there is no change in values provider should not update resource

Actual Behavior

Provider is updating values of availability_type and gce_zone on every run irrespective of change.

Steps to Reproduce

Rerun code multiple times. It will update values of availability_type and gce_zone

1. terraform apply 2.terraform apply

Important Factoids

References

• 0000

b/354771977

[edwardmedia]

@imrannayer can you share your debug log?

[imrannayer]

alloydb_tf.log

[imrannayer]

@edwardmedia any update on this?

[revero-doug]

applies to primary instances as well

[edwardmedia]

availability_type and gce_zone are missing in the api response

b/272346276

[c2thorn]

Adding a note that as a temporary workaround users can use lifecycle ignore_changes to ignore the availability_type and gce_zone perma-diffs.

[melinath]

The API should now return availability_type.

[SarahFrench]

I've been looking into this in response to a customer issue, and FWIW I can see that GET requests for primary instances return the availabilityType field but that isn't the case for read pool instances (and neither instance type returns the gceZone).

Primary instance:

GET /v1/projects/redacted/locations/us-central1/clusters/alloydb-cluster-all/instances/primary-instance-1

 ---[ RESPONSE ]--------------------------------------
 HTTP/2.0 200 OK
 Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
 Cache-Control: private
 Content-Type: application/json; charset=UTF-8
 Date: Thu, 09 Nov 2023 12:07:53 GMT
 Server: ESF
 Vary: Origin
 Vary: X-Origin
 Vary: Referer
 X-Content-Type-Options: nosniff
 X-Frame-Options: SAMEORIGIN
 X-Xss-Protection: 0

 {
   "name": "projects/redacted/locations/us-central1/clusters/alloydb-cluster-all/instances/primary-instance-1",
   "uid": "f73c5058-1e99-43c0-baf6-d7ce947b2695",
   "createTime": "2023-11-09T11:35:17.556146829Z",
   "updateTime": "2023-11-09T11:53:17.875659511Z",
   "state": "READY",
   "instanceType": "PRIMARY",
   "machineConfig": {
     "cpuCount": 2
   },
   "availabilityType": "ZONAL",
   "ipAddress": "10.35.0.2",
   "reconciling": false,
   "writableNode": {
     "zoneId": "us-central1-b"
   },
   "queryInsightsConfig": {
     "recordApplicationTags": false,
     "recordClientAddress": false,
     "queryStringLength": 1024,
     "queryPlansPerMinute": 5
   }
 }

Read pool instance:

GET /v1/projects/redacted/locations/us-central1/clusters/alloydb-cluster-all/instances/read-instance-1

 ---[ RESPONSE ]--------------------------------------
 HTTP/2.0 200 OK
 Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
 Cache-Control: private
 Content-Type: application/json; charset=UTF-8
 Date: Thu, 09 Nov 2023 11:49:33 GMT
 Server: ESF
 Vary: Origin
 Vary: X-Origin
 Vary: Referer
 X-Content-Type-Options: nosniff
 X-Frame-Options: SAMEORIGIN
 X-Xss-Protection: 0

 {
   "name": "projects/redacted/locations/us-central1/clusters/alloydb-cluster-all/instances/read-instance-1",
   "uid": "0244997a-be1e-49a6-a74f-4eb53f4ef314",
   "createTime": "2023-11-09T11:43:18.523217489Z",
   "updateTime": "2023-11-09T11:49:27.158284795Z",
   "state": "READY",
   "instanceType": "READ_POOL",
   "machineConfig": {
     "cpuCount": 8
   },
   "readPoolConfig": {
     "nodeCount": 1
   },
   "ipAddress": "10.35.0.5",
   "reconciling": false,
   "queryInsightsConfig": {
     "recordApplicationTags": false,
     "recordClientAddress": false,
     "queryStringLength": 1024,
     "queryPlansPerMinute": 5
   }
 }

And as a result the permadiff is either one or two fields:

[dorz-saymine]

still an issue. any update on this?

[melinath]

Marking for re-forwarding.