-
Notifications
You must be signed in to change notification settings - Fork 248
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
newrelic_entity_tags is deleting "default" tags on every plan/apply #766
Comments
I redacted below output to show which tags are being deleted in our case.
|
I have seen that as well and those are OOB tags that just gets tagged as to be destroyed but not sure if TF APPLY can actually delete those tags. |
@trunet Hi there! Thanks for reporting this. Oddly enough I was only able to reproduce this the first time I tried, but I haven't been able to reproduce it again after many attempts. Is this an intermittent issue or can this be reproduced every time for you? Here is the config I'm using: provider "newrelic" {
version = "2.2.1"
}
locals {
tags = {
tagKey = "tagvalue",
}
common = {
commontag = "commontagvalue",
}
}
data "newrelic_entity" "ssl" {
name = "Dummy App"
domain = "APM"
}
resource "newrelic_entity_tags" "ssl" {
guid = data.newrelic_entity.ssl.guid
dynamic "tag" {
for_each = merge(local.tags, local.common)
content {
key = tag.key
values = list(tag.value)
}
}
} |
@sanderblue for me, it changes almost every time. My guess is that the tags are re-added when the actual synthetics monitoring runs. like, if you're running SSL check once a day, it will be re-added every day. My more frequent monitoring I can see it changing often. |
I'm trying to find someone to tell me how we can identify user-added tags, which would allow us to constrain the view that TF has. Otherwise, another suggestion for a fix here is to ignore everything that we've not defined in manifest, which would avoid the constant attempt at removing tags that the synthetics service keeps adding. I'm trying to think of unintended consequences to the later solution, but haven't come up with any yet. |
@zlesnr - In the New Relic One UI's Entity Exporer, we can only remove user-added tags when the "Remove Tags" option is turned-on so I would assume there would be metadata to entity tags that separates/distinguishes the system vs user-added: |
Oh neat. I have the same assumption, but I need to figure out the graphql mechanics to make it work. I'm issuing the following query, which contains no information about which of these were added by the user. https://api.newrelic.com/graphiql
|
@zlesnr - you are correct. I ran the same query for our account against one of our synthetic and I see no information to say which ones were system vs user-added. |
Ah, I've learned that part of the schema is hidden, and there are details about the tag metadata there. I'm chasing it down to see if we might move that portion of the schema into the public so that TF could learn which tags are mutable. |
Discussions must take place. I should know more tomorrow. 🍿 |
I'm hearing soonish before the schema will be public. |
@zlesnr - Any updates on these "default" tags? |
Looks like that work is happening now and is currently in review. |
Looking forward to resolution of this issue. |
Using New Relic Provider v2.7.1 I have confirmed that the "default" entity tags for our Synthetics are now longer showing after we run terraform plan. Thanks for fixing this issue @zlesnr. |
I can confirm 2.7.1 fixed this issue. thank you all. Closing! |
Woo woo. I forgot to close this out, so thanks for coming back. |
Terraform Version
Terraform v0.13.0-beta3
Affected Resource(s)
Terraform Configuration Files
Expected Behavior
After first apply, it shouldn't on subsequent runs to delete tags.
Actual Behavior
On every terraform plan/apply it asks to delete some tags. Looks like these tags are re-created automatically by newrelic.
Steps to Reproduce
terraform apply
sleep 300 # sometimes these tags takes some time to be recreated by newrelic
terraform apply
The text was updated successfully, but these errors were encountered: