The newrelic_alert_channel resource's include_json_attachment config cannot be enabled by either 1 or "1"; it's just stuck switched off. Documentation link.
terraform {
required_version = "~> 0.14.0"
required_providers {
newrelic = {
source = "newrelic/newrelic"
version = "~> 2.16.0"
}
}
}
resource "newrelic_alert_channel" "email_me" {
name = "Email : [email protected]"
type = "email"
config {
recipients = "[email protected]"
include_json_attachment = "1"
}
}
Also raised on forum. Thanks for your time.
@rdhar so even if you apply a value of 1 to that field, it operates as it's set 0 ?
include_json_attachment - (Optional) 0 or 1. Flag for whether or not to attach a JSON document containing information about the associated alert to the email that is sent to recipients.
Hi @jpvajda, that's correct. It cannot be enabled by either 1 or "1"; it's just stuck switched off.
@rdhar have you tried leaving it as a empty string? ""
@jpvajda So far I've tried:
1"1"""None of these options have enabled "JSON attachment" for email notification channels.
As an added hassle, this also highlights the issue raised in #1130, whereby all alert resources associated with newrelic_alert_policy_channel鈥攊.e., policies, conditions and the channel itself鈥攁re recreated from scratch instead of just being modified. Polluting the logs and causing unnecessary friction. Why is this the case?
EDIT
Out of curiosity, I tried passing true: it worked! 馃帀
For context, I'm on Terraform v0.14.6 using New Relic provider v2.17.0.
@rdhar interesting... we'll look into this... thanks for trying some different options to get it to work!
@jpvajda Thank you for bearing with me, I appreciate your time.
Really positive to see that the aforementioned #1130 has been picked up as well! Given our set up of 100s of alerts associated with a handful of notification channels, it's painful to watch them all being destroyed and re-created just for a minor tweak in the channel config.
@rdhar Definitely! We appreciate the due diligence in reporting issues you are finding.
This issue has been automatically marked as stale because it has not had any recent activity. It will be closed if no further activity occurs.
Looks like a backend API change requiring a more specific value. Should be resolved in #1259