terraform-provider-newrelic
terraform-provider-newrelic copied to clipboard
`newrelic_notification_destination` updates with every apply to delete `auth_basic`
:warning: Important: Failure to include the following, such as omitting the Terraform configuration in question, may delay resolving the issue.
- [x] Your New Relic
provider
configuration (sensitive details redacted) - [x] A list of affected resources and/or data sources
- [x] The configuration of the resources and/or data sources related to the bug report (i.e. from the list mentioned above)
- [x] Description of the current behavior (the bug)
- [x] Description of the expected behavior
- [x] Any related log output
Terraform Version
terraform -v
Terraform v1.2.9
on darwin_amd64
+ provider registry.terraform.io/hashicorp/aws v4.30.0
+ provider registry.terraform.io/newrelic/newrelic v3.2.1
Affected Resource(s)
-
newrelic_notification_destination
Terraform Configuration
provider.tf
:
terraform {
required_version = "~> 1.2.9"
required_providers {
newrelic = {
source = "newrelic/newrelic"
version = "~> 3.2.1" # same for 3.2.0
}
}
}
provider "newrelic" {
region = var.newrelic_region
}
alerts.tf
:
resource "newrelic_notification_destination" "google_chat_temp" {
name = "TF Google Chat"
type = "WEBHOOK"
property {
key = "url"
value = "https://chat.googleapis.com/v1/spaces/*redacted*"
}
}
Actual Behavior
What actually happened?
- terraform plan / apply wants to update the webhook destination and delete the
auth_basic {}
attribute even though it is not defined in the resource.
Expected Behavior
What should have happened?
- The resource should not get updated every time. The attribute is not included so terraform should not detect anything at all.
- terraform apply should alter the resource accordingly
Steps to Reproduce
Please list the steps required to reproduce the issue, for example:
-
terraform plan / apply
- then to see that the problem still exists, another
terraform plan / apply
Debug Output
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
~ update in-place
Terraform will perform the following actions:
# newrelic_notification_destination.google_chat_temp will be updated in-place
~ resource "newrelic_notification_destination" "google_chat_temp" {
id = "*redacted*"
name = "TF Google Chat"
# (4 unchanged attributes hidden)
- auth_basic {}
# (1 unchanged block hidden)
}
Plan: 0 to add, 1 to change, 0 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
newrelic_notification_destination.google_chat_temp: Modifying... [id=*redacted*]
newrelic_notification_destination.google_chat_temp: Modifications complete after 1s [id=*redacted*]
Apply complete! Resources: 0 added, 1 changed, 0 destroyed.
Hi @louhnmn thanks for raising the issue. We will prioritise it.
Hi @NSSPKrishna I can confirm this bug, we see the ery same behaviour.
fyi: this is still included in v3.4.3
Hi, I am on the latest version i.e. 3.5.0 and I am getting this issue.
"newrelic_notification_destination" gets updated in place every time when there is no change in the terraform configuration.
================
newrelic_notification_destination.webhook-squadcast will be updated in-place
resource "newrelic_notification_destination" "webhook-squadcast" { id = "ID Goes Here" name = "name Goes Here" # (4 unchanged attributes hidden)
-
auth_basic {}
-
property {
- key = "source" -> null
- label = "terraform-source-internal" -> null
- value = "terraform" -> null }
-
property {
- key = "url" -> null
- value = "URL endpoint Goes Here" -> null }
- property {
- key = "source"
- label = "terraform-source-internal"
- value = "terraform" }
- property {
- key = "url"
- value = "URL endpoint Goes Here" } }
=============
cc: @IliaShurygin
Any updates on this?
Hi everyone!
Our current plan is to fix this problem (both auth_basic
and property
) some time later this quarter, but not as the highest priority.
I understand that this issue causes additional noice and potential problems with CICD pipelines, but it should not prevent users from managing destinations entirely, hence the lower priority. This is not to say that this is not a significant flaw, but it is not the most urgent one to fix.
If this problem actually blocks you from managing destinations via TF, please let us know about your workflow! We would be happy to better understand how people use our provider and reassess priorities accordingly.
I'd like to add that it shows repeatedly updating values for properties that are already applied, not just deleting auth_basic.
I am running
Terraform v1.3.3
on darwin_arm64
+ provider registry.terraform.io/newrelic/newrelic v3.6.1
I have this in main.tf:
resource "newrelic_notification_destination" "alert_email_destination" {
name = "alert-email"
type = "EMAIL"
property {
key = "email"
value = "mixxxm"
}
}
and if I run apply twice in a row, it always shows this same output:
# newrelic_notification_destination.alert_email_destination will be updated in-place
~ resource "newrelic_notification_destination" "alert_email_destination" {
id = "b863xxx0cdc"
name = "alert-email"
# (4 unchanged attributes hidden)
- auth_basic {}
- property {
- key = "email" -> null
- value = "mixxxom" -> null
}
- property {
- key = "source" -> null
- label = "terraform-source-internal" -> null
- value = "terraform" -> null
}
+ property {
+ key = "email"
+ value = "mixxxm"
}
+ property {
+ key = "source"
+ label = "terraform-source-internal"
+ value = "terraform"
}
}
I somehow missed this issue and wrote a new one about it but now that I found @IliaShurygin's comment above I've closed it: https://github.com/newrelic/terraform-provider-newrelic/issues/2099
I hope this gets prioritized although I understand why it's not highest priority.
A temporary work around for the flapping might be to use lifecycle ignore_changes?
lifecycle {
ignore_changes = [ auth_basic, property ]
}
Hi everyone,
The auth_basic
issue is fixed in the latest version (3.8.0).
Closing this issue as it is resolved. If the issue persists please get back to us.