Terraform-provider-newrelic: provider/newrelic: newrelic_alert_channel continually recreates resources

[hashibot]

_This issue was originally opened by @silvamerica as hashicorp/terraform#13401. It was migrated here as part of the provider split. The original body of the issue is below._

---

Terraform Version

0.9.2

Affected Resource(s)

• newrelic_alert_channel
• newrelic_alert_policy_channel

Terraform Configuration Files

resource "newrelic_alert_policy" "alerting" {
  name = "${var.name}-${var.environment}"
}

resource "newrelic_alert_channel" "alerting" {
  name = "${var.name}-pagerduty-${var.environment}"
  type = "pagerduty"

  configuration = {
    subdomain = "${var.subdomain}"
    service_name = "${pagerduty_service_integration.newrelic.name}"
    service_key = "${pagerduty_service_integration.newrelic.integration_key}"
  }
}

resource "newrelic_alert_policy_channel" "alerting" {
  policy_id  = "${newrelic_alert_policy.alerting.id}"
  channel_id = "${newrelic_alert_channel.alerting.id}"
}

Expected Behavior

No changes should be detected

Actual Behavior

-/+ module.alerting.newrelic_alert_channel.alerting
    configuration.%:            "0" => "3" (forces new resource)
    configuration.service_key:  "<sensitive>" => "<sensitive>" (forces new resource)
    configuration.service_name: "<sensitive>" => "<sensitive>" (forces new resource)
    configuration.subdomain:    "<sensitive>" => "<sensitive>" (forces new resource)
    name:                       "alerting-pagerduty-production" => "alerting-pagerduty-production"
    type:                       "pagerduty" => "pagerduty"

-/+ module.alerting.newrelic_alert_policy_channel.alerting
    channel_id: "223790" => "0" (forces new resource)
    policy_id:  "57733" => "57733"

It seems like the configuration hash might not be being sent from the newrelic API, therefore the newrelic provider thinks it has to re-add it every time.

[dnesting]

I'm hitting this too. Playing with the NR API explorer at https://rpm.newrelic.com/api/explore/alerts_channels/list, I see the configuration contains some fields for some channel types (e.g. e-mail) but is missing information for other types (pagerduty). Creating new objects works fine (i.e., letting this apply will result in correctly re-creating objects). I opened New Relic support ticket 256717 to ask if this is expected behavior or not. If it is, maybe we need to record these things in the state file and presume that they're still set as-is if NR does not return them in a read.

[dnesting]

Confirmed that this is expected behavior that we'll need to work around in the New Relic provider.

I have checked this with our development and team and they have confirmed that these fields are stripped out for security purposes.

I don't have an exhaustive list of the fields that are stripped out in this way, however any fields that is obfuscated in the UI will be stripped out by the API.

[jamielennox]

Support request on newrelic forums: https://discuss.newrelic.com/t/feature-idea-use-api-to-update-alert-channels/

[jamielennox]

Note, to make this usable in my environment I can set the ignore_changes= variable so at least it doesn't recreate on every run.

resource "newrelic_alert_channel" "channel" {
  name = "Dev/${var.service_name}"
  type = "pagerduty"
  configuration = {
    service_key = "${pagerduty_service_integration.newrelic.integration_key}"
  }
  lifecycle {
    ignore_changes = ["configuration"]
  }
}

Obviously it'll never update if the service changes, but it's better than recreating the channel every time for me.

[paddie]

Yes, hitting this as well. Using @jamielennox 's workaround for now to not break all the automation that is surrounding the assumed immutability of alert channels.

But, if the resources that channels depend on change (which in our case they can) we have to recreate these resources by manually tainting each of them.. which can be a bit annoying.

[ConstantinElse]

I'm having the same issue with slack channel too:

resource "newrelic_alert_channel" "slack" {
  name = "alerts"
  type = "slack"

  configuration = {
    channel = "alerts"
    url     = "https://hooks.slack.com/services/***********"
  }
}

getting all the time:

-/+ newrelic_alert_channel.slack (new resource required)
      id:                    "1634652" => <computed> (forces new resource)
      configuration.%:       "1" => "2" (forces new resource)
      configuration.channel: <sensitive> => <sensitive> (attribute changed)
      configuration.url:     <sensitive> => <sensitive> (forces new resource)
      name:                  "alerts" => "alerts"
      type:                  "slack" => "slack"

[phoenixrising87]

Ignoring changes from @jamielennox is also working for me as a workaround. But are there any updates on this?

[0x91]

Is there any update on this issue?

[hoshsadiq]

Would appreciate a fix for this. We're currently manually creating the channels and passing them in as a variable. Will probably try the lifecycle ignore_changes workaround.

EDIT: never mind. Having investigated I can see that this is gonna be hard to implement without New Relic's willingness to update their API and/or create a new end point.

[ctrombley]

This behavior is intentional. The underlying API endpoint that is used to read channel resources intentionally obfuscates (strips) JSON attributes that are known to contain sensitive data, such as the pagerduty channel's service_key endpoint. The provider assumes that the resource will need to be recreated every time to account for this, since it cannot tell if the underlying data has changed.

In a scenario where the configuration is known to be static and performance is a concern, the approach @jamielennox is using is probably the best solution.