NewNotificationChannel property diff for each run #875
Comments
raywonkari
added
kind/bug
|
when we also look at the NR generated code from the console, we also see these fields |
|
hi @raywonkari - thank you for filing this issue. We're sorry you're having trouble here and will take a look. It does appear as though a TF property is leaking through - upstream seems to have a diff suppress function for this, but we don't seem to follow this pattern. Do you happen to know if this behavior is a recent change? Meaning, were you using earlier versions of this provider and did not see this diff? |
guineveresaenger
added
awaiting-feedback
|
hi again @raywonkari - I'm going to need a little help with a reproduction, as I'm not as familiar with the ins and outs of New Relic. Specifically, can you provide us with a complete program that reproduces this issue you're seeing? This would help us address and root cause much more quickly. |
|
Thanks @guineveresaenger, we have recently started using this method from the SDK, so I am not sure if this diffs are popping up now, or were there from the beginning. The code pasted in the issue description should be good enough I think, we just have to create a new pulumi project and then paste that code in and apply, and then see a potential diff in the next run.. if you do not have a newrelic account, may be it is a bit tricky to reproduce I guess.. The only prerequisite is the destinationId, I guess for that, just create a new destination from new relic UI manually and then extract the ID.. It can be created by logging in to newrelic console -> Alerts -> Destinations -> Add a destination. |
pulumi-bot
added
needs-triage
|
@guineveresaenger I was able to reproduce with this program (and the package main
import (
"github.com/pulumi/pulumi-newrelic/sdk/v5/go/newrelic"
"github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)
func main() { pulumi.Run(Main) }
func Main(ctx *pulumi.Context) error {
d, err := newrelic.NewNotificationDestination(ctx, "d", &newrelic.NotificationDestinationArgs{
Properties: &newrelic.NotificationDestinationPropertyArray{},
Type: pulumi.String("WEBHOOK"),
})
if err != nil {
return err
}
_, err = newrelic.NewNotificationChannel(ctx, "example", &newrelic.NotificationChannelArgs{
Name: pulumi.String("example"),
Type: pulumi.String("WEBHOOK"),
DestinationId: d.ID(),
Product: pulumi.String("IINT"),
Properties: newrelic.NotificationChannelPropertyArray{
&newrelic.NotificationChannelPropertyArgs{
Key: pulumi.String("payload"),
Value: pulumi.String("my-payload"),
},
},
})
return err
}I see a perma-diff for both the notification destination and the notification channel. |
iwahbe
added
bug/diff
|
I have reproduced the above code in HCL and tested against the upstream TF provider. There is no perma-diff, indicating a bridge bug. terraform {
required_providers {
newrelic = {
source = "newrelic/newrelic"
}
}
}
resource "newrelic_notification_destination" "example" {
name = "example"
property {
key = "my-key"
value = "my-value"
}
type = "WEBHOOK"
}
resource "newrelic_notification_channel" "example" {
name = "example"
type = "WEBHOOK"
destination_id = newrelic_notification_destination.example.id
product = "IINT"
property {
key = "payload"
value = "my-payload"
}
} |
iwahbe
added
the
awaiting/bridge
|
Thank you for narrowing it down 🙏 Does the perma-diff in TF exist under |
No. TF does not have the perma-diff regardless of refresh.
We don't have PRC turned on in this provider (CC @VenelinMartinov, I thought we had this rolled out to all providers). PRC fixes the problem. Thanks for the suggestion. |
iwahbe
removed
the
awaiting/bridge
|
This issue has been addressed in PR #877 and shipped in release v5.32.1. |
Describe what happened
We create a webhook channel with a property info containing a payload, values etc. However after the initial deployment, subsequent pulumi up's show a terraform specific property popping up, which is not needed I guess. Perhaps the underlying terraform code is appending these fields.
Sample program
pulumi diff (fields are masked)
Log output
No response
Affected Resource(s)
No response
Output of
pulumi aboutsome fields are masked
Additional context
No response
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).
The text was updated successfully, but these errors were encountered: