Resource newrelic_cloud_gcp_integrations: Now Requires Optional Properties to be Set to Avoid Drift

[a88zach]

Terraform Version

Terraform v1.9.8 on darwin_arm64

Affected Resource(s)

Please list the resources as a list, for example:

• newrelic_cloud_gcp_integrations

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration

Please include your provider configuration (sensitive details redacted) as well as the configuration of the resources and/or data sources related to the bug report.

resource "newrelic_cloud_gcp_link_account" "prod" {
  project_id = "prod"
  name       = "prod"
}

resource "newrelic_cloud_gcp_integrations" "prod" {
  linked_account_id = newrelic_cloud_gcp_link_account.prod.id
  big_query {}
  functions {}
  redis {}
  run {}
  virtual_machines {}
}

Actual Behavior

With the above configuration, the integration blocks are removed from the integration

Expected Behavior

The integration blocks should use the default values for fetch_tags and metrics_polling_interval

Steps to Reproduce

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

1. terraform apply

Important Factoids

This happens when moving from 3.51.0 to 3.52.0
This is fixed by adding the defaults to the integration blocks

resource "newrelic_cloud_gcp_integrations" "prod" {
  linked_account_id = newrelic_cloud_gcp_link_account.prod.id
  big_query {
    fetch_tags               = true
    metrics_polling_interval = 300
  }
  functions {
    metrics_polling_interval = 300
  }
  redis {
    metrics_polling_interval = 300
  }
  run {
    metrics_polling_interval = 300
  }
  virtual_machines {
    metrics_polling_interval = 300
  }
}

[pranav-new-relic]

Hi @a88zach, I just tried reproducing this, and this seems to be the case with earlier versions of the provider too, such as 3.51.0, 3.40.0 and many more in the past. This seems to have been the behaviour for quite some time now, given the Terraform Provider does not have defaulting behaviour of the metrics_polling_interval, etc; we generally do not add such rigid default values to avoid concerns when such default values are changed upstream.

Can you please test this on 3.51.0 and previous versions and let us know if you're seeing the same behaviour too? This would help conclude that this is not a breaking change caused in 3.52.0 (while that is not possible, considering no changes were made to the newrelic_cloud_gcp_integrations resource).

[a88zach]

@pranav-new-relic, my hunch here is that something may have changed in the nerdgraph, but I cannot find that code to verify.

I now get the same result using both 3.52.0 and 3.51.0, but my configuration hasn't changed since 3.30.0 (see below)

resource "newrelic_cloud_gcp_integrations" "prod" {
  linked_account_id = newrelic_cloud_gcp_link_account.prod.id
  big_query {}
  functions {}
  redis {}
  run {}
  virtual_machines {}
}

However, with this configuration, a new plan is created each time that tries to remove the integrations default arguments. If you set up a resource like above, and run an apply multiple times without changing the resource, you should see the issue.

According to the docs for this resource the integration arguments are all optional with defaults

[pranav-new-relic]

@a88zach I kinda agree with you - after having gone through the code again, I seem to realise this is probably not how the resource behaved so far; why I still am not (and was previously not) 100% sure is because the API did exhibit such flakey behaviour occasionally in the past, I'm wondering if that is a similar scenario.

I'll try checking with the API folks here at New Relic to see if they've changed something that's causing this behavior.

[pranav-new-relic]

Hi @a88zach, the API team that maintains the relevant service on NerdGraph here at New Relic has confirmed to us that a change was indeed made, owing to a migration of cloud integration services that is in progress. They're currently analyzing if the change made can be rolled back, in order to prevent this behaviour with the Terraform resource. However, this would take them quite a bit of time, given the technical bottlenecks with having this done; hence, in the interim, I'd like to request you to continue to use values of these arguments with each of the integration blocks. Thank you for your patience.