Terraform-provider-newrelic: Upgrade to 1.13.0 breaks newrelic_alert_condition resource where condition_scope was not specified

[pickgr]

Terraform Version

Terraform v0.11.11

• provider.newrelic v1.13.0

Affected Resource(s)

newrelic_alert_condition

Terraform Configuration Files

I think this can be reproduced with the example at
https://www.terraform.io/docs/providers/newrelic/r/alert_condition.html

Expected Behavior

Before version 1.13.0, https://www.terraform.io/docs/providers/newrelic/r/alert_condition.html was optional. When upgrading the provider, it must be added to the code. However, after running apply, followed by a subsequent plan, the resource still shows drift for condition_scope

Actual Behavior

There should be no drift after adding condition_scope to the code and updating the provider.

Steps to Reproduce

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

1. terraform plan with 1.12.2 verify no drift
2. terraform plan with 1.13.0 - error regarding conditional_scope being mandatory
3. specify conditional_scope in the resource
4. terraform apply
5. terraform plan observe that the resource still shows drift

Reverting to 1.12.2 is the only work-around I could find.

References

Most likely related to these changes

https://github.com/terraform-providers/terraform-provider-newrelic/compare/v1.12.2...v1.13.0#diff-59adf773b6a5d1a8d428c72e2986db6aR121

[zlesnr]

Hi @pickgr, I'm unable to reproduce the issue here using the manifest in the alert_condition documentation you linked. Too, I'm not able to create the resource at all using either version of the provider unless the condition_scope is set. I get a 422 from the server.

Error: 422 response returned: `condition_scope` must be `application` or `instance`.

  on test.tf line 11, in resource "newrelic_alert_condition" "foo":
  11: resource "newrelic_alert_condition" "foo" {

I can confirm though, that creating the resource on an older version results in an empty plan on both the old and newer versions.

When you revert to the old version, do you also keep the condition_scope set in the manifest? Any more detail on your manifest would be helpful for me to try and reproduce this.

[pickgr]

@zlesnr

Hopefully this will help

Original code:

resource "newrelic_alert_condition" "livedoc_generation_response_time" {
  entities = [
    data.newrelic_key_transaction.livedoc_generation_prod_westus.id,
    data.newrelic_key_transaction.livedoc_generation_prod_westus2.id,
    data.newrelic_key_transaction.livedoc_generation_prod_eastus.id,
    data.newrelic_key_transaction.livedoc_generation_prod_westeurope.id,
    data.newrelic_key_transaction.livedoc_generation_prod_canadacentral.id,
    data.newrelic_key_transaction.livedoc_generation_prod_australiasoutheast.id,
  ]

  metric      = "response_time"
  name        = "LiveDoc fabric engine response time (High)"
  policy_id   = data.newrelic_alert_policy.livedoc_notify_pagerduty.id
  runbook_url = "https://seismic.atlassian.net/wiki/spaces/LT/pages/1151112215"

  term {
    duration      = 10
    operator      = "above"
    priority      = "critical"
    threshold     = "300"
    time_function = "all"
  }

  type = "apm_kt_metric"
}

Upgrade provider from 1.12.2 to 1.13.0. The following error is seen without condition_scope specified:

Error: Missing required argument

  on livedoc_alert_conditions.tf line 1, in resource "newrelic_alert_condition" "livedoc_generation_response_time":
   1: resource "newrelic_alert_condition" "livedoc_generation_response_time" {

The argument "condition_scope" is required, but no definition was found.

New code:

resource "newrelic_alert_condition" "livedoc_generation_response_time" {
  condition_scope = "application"

  entities = [
    data.newrelic_key_transaction.livedoc_generation_prod_westus.id,
    data.newrelic_key_transaction.livedoc_generation_prod_westus2.id,
    data.newrelic_key_transaction.livedoc_generation_prod_eastus.id,
    data.newrelic_key_transaction.livedoc_generation_prod_westeurope.id,
    data.newrelic_key_transaction.livedoc_generation_prod_canadacentral.id,
    data.newrelic_key_transaction.livedoc_generation_prod_australiasoutheast.id,
  ]

  metric      = "response_time"
  name        = "LiveDoc fabric engine response time (High)"
  policy_id   = data.newrelic_alert_policy.livedoc_notify_pagerduty.id
  runbook_url = "https://seismic.atlassian.net/wiki/spaces/LT/pages/1151112215"

  term {
    duration      = 10
    operator      = "above"
    priority      = "critical"
    threshold     = "300"
    time_function = "all"
  }

  type = "apm_kt_metric"
}

New plan:

Terraform will perform the following actions:

  # newrelic_alert_condition.livedoc_generation_response_time will be updated in-place
  ~ resource "newrelic_alert_condition" "livedoc_generation_response_time" {
      + condition_scope       = "application"
        enabled               = true
        entities              = [
            41080,
            41081,
            41082,
            41083,
            41084,
            41085,
        ]
        id                    = "590336:11406144"
        metric                = "response_time"
        name                  = "LiveDoc fabric engine response time (High)"
        policy_id             = 590336
        runbook_url           = "https://seismic.atlassian.net/wiki/spaces/LT/pages/1151112215"
        type                  = "apm_kt_metric"
        violation_close_timer = 0

        term {
            duration      = 10
            operator      = "above"
            priority      = "critical"
            threshold     = 300
            time_function = "all"
        }
    }

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

Try applying change:

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

Subsequent plan still shows drift:

Terraform will perform the following actions:

  # newrelic_alert_condition.livedoc_generation_response_time will be updated in-place
  ~ resource "newrelic_alert_condition" "livedoc_generation_response_time" {
      + condition_scope       = "application"
        enabled               = true
        entities              = [
            41080,
            41081,
            41082,
            41083,
            41084,
            41085,
        ]
        id                    = "590336:11406144"
        metric                = "response_time"
        name                  = "LiveDoc fabric engine response time (High)"
        policy_id             = 590336
        runbook_url           = "https://seismic.atlassian.net/wiki/spaces/LT/pages/1151112215"
        type                  = "apm_kt_metric"
        violation_close_timer = 0

        term {
            duration      = 10
            operator      = "above"
            priority      = "critical"
            threshold     = 300
            time_function = "all"
        }
    }

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

To revert I change the provider version back to 1.12.2 and also remove _condition_scope_

[pickgr]

Also, not sure if this is helpful, but here what the NR API returns for that condition:

{
  "conditions": [
    {
      "id": 11406144,
      "type": "apm_kt_metric",
      "name": "LiveDoc fabric engine response time (High)",
      "enabled": true,
      "entities": [
        "41081",
        "41080",
        "41084",
        "41085",
        "41082",
        "41083"
      ],
      "metric": "response_time",
      "runbook_url": "https://seismic.atlassian.net/wiki/spaces/LT/pages/1151112215",
      "terms": [
        {
          "duration": "10",
          "operator": "above",
          "priority": "critical",
          "threshold": "300",
          "time_function": "all"
        }
      ]
    },
.
.
.

[zlesnr]

Yes, thanks for that. Just to confirm, it looks like that last payload is missing condition_scope from the object. I'm wondering if something has changed recently with the API and what we should do is recreate the object in question. The responses I have coming back from the server contain the condition_scope field.

[zlesnr]

v1.13.1 includes the fix here. Let me know if this is not resolved for you @pickgr.

[pickgr]

@zlesnr Everything looks good in 1.13.1. Thanks for the quick turn-around!

[zlesnr]

Glad to hear it @pickgr. Thanks for raising the issue. I got to learn something about the API I didn't know before.