Terraform v0.12.29
Please list the resources as a list, for example:
newrelic_alert_conditionPlease include your
providerconfiguration (sensitive details redacted) as well as the configuration of the resources and/or data sources related to the bug report.
terraform {
required_version = "= 0.12.29"
}
provider "newrelic" {
account_id = var.account_id
admin_api_key = var.admin_api_key
api_key = var.api_key
region = var.region
version = "= 2.13.5"
}
data "newrelic_entity" "service1" {
name = "Service 1"
}
data "newrelic_entity" "service2" {
name = "Service 2"
}
resource "newrelic_alert_condition" "apdex_critical_service_apps" {
condition_scope = "application"
entities = [
data.newrelic_entity.service1_id,
data.newrelic_entity.service2_id
]
metric = "apdex"
name = "Service Apdex (Low) - Critical"
policy_id = data.newrelic_alert_policy.foo.id
term {
duration = 10
operator = "below"
priority = "critical"
threshold = "0.5"
time_function = "all"
}
type = "apm_app_metric"
}
The data source for data.newrelic_entity.service2_id is returning an incorrect ID. service1 works OK
Error: 422 response returned: Invalid entity id(s): 123456790.
All data sources should return the correct ID.
Please list the steps required to reproduce the issue, for example:
terraform initterraform plan # shows drift for the ID in the entiriesterraform apply # shows the error aboveI suspect this is account specific and will be difficult to reproduce without access to our account. Also, this problem is not see when using the older data source for newrelic_application. Upgrading to use newrelic_application caused this issue.
We changed the data source because of this warning:
Warning: Use the `newrelic_entity` data source instead.
Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:
Could not find anything
I'll try to reproduce this today thanks for making us aware of the problem @pickgr
@pickgr curious are these entity names
entities = [
data.newrelic_entity.service1_id,
data.newrelic_entity.service2_id
]
obfuscated? I was looking up the entity on our side and couldn't find any by this name associated with your account.
@jpvajda those were dummy names I used for the PR.
These are the actual
- data.newrelic_entity.firestorm_service_prod_useast.application_id
+ # TODO - the following returns 705936293 ??
+ # data.newrelic_entity.firestorm_service_prod_useast.application_id
Thank you for investigating.
@jpvajda - I just realized that I didn't include the actual name of the entity/application above.
# TODO
# data "newrelic_entity" "firestorm_service_prod_useast" {
data "newrelic_application" "firestorm_service_prod_useast" {
name = "Firestorm Service - Prod - IBM - USEast"
}
@pickgr Thank you! I do see 2 existing alerts on that entity, 1 seems to match your Terraform configuration . Policy Id: 679620
聽 | Firestorm Service Service Apdex (Low) - Critical | Apdex < 0.5 for at least 10m CRITICAL | Sep 11, 8:04 am |
Was this an attempt to create a new alert condition on that entity or modify an existing?
@jpvajda we were trying to modify an existing and replace the newrelic_application data source which is being deprecated per the warning above with newrelic_entity
Hey @pickgr! You'll want to use data.newrelic_entity.service1.application_id instead of data.newrelic_entity.service1.id when populating the entities field in newrelic_alert_condition. It is a bit of an unfortunate naming convention that was put in place a while ago that has led to some confusion. Give that a try and let us know how it goes!
@ctrombley please see my recent comments above. We are using data.newrelic_entity.service1.application_id and it returns a different ID from when we used data.newrelic_application.service.id
We have a meeting setup with our account team on (Brian Rogers) Monday to hopefully demonstrate the issue so it's clear.
At a quick glance, this looks similar to https://github.com/newrelic/terraform-provider-newrelic/issues/1016
In some cases the API returns a different ID than the user is expecting, and so in the case of #1016 because it was a browser entity, the reference needed to point at the browser_id iirc.
Hey @pickgr, I think I see what's happening here. You have an app named "Firestorm Service - Prod - IBM - USEast" in two of your accounts, but the newrelic_entity data source is not yet defaulting its account_id from the provider config. The API is returning 2 applications and the provider is just grabbing the first one, which in this case is incorrect. We'll take an action item to get that in place, but for the meantime you should be able to specify your account ID in the newrelic_entity data source's config with the accountId attribute to uniquely identify your application.
@ctrombley - that definitely sounds like it could be the issue. Thanks!
I'm having trouble with the work-around you suggested.
Error: Unsupported argument
on data.tf line 47, in data "newrelic_entity" "firestorm_service_prod_useast":
47: accountId = "${var.account_id}"
An argument named "accountId" is not expected here. Did you mean "account_id"?
So I tried account_id and get this:
Error: "account_id": this field cannot be set
on data.tf line 46, in data "newrelic_entity" "firestorm_service_prod_useast":
46: data "newrelic_entity" "firestorm_service_prod_useast" {
Here's the code:
data "newrelic_entity" "firestorm_service_prod_useast" {
account_id = "${var.account_id}"
name = "Firestorm Service - Prod - IBM - USEast"
}
@pickgr I made a mistake here, it looks like we don't have account_id plumbed in as a search parameter like I thought we did. It's just a computed attribute. However, what you can do is use the automatic accountId entity tag in your data source config:
data "newrelic_application" "firestorm_service_prod_useast" {
name = "Firestorm Service - Prod - IBM - USEast"
tag {
key = "accountId"
value = "${var.account_id}"
}
}
Let us know if this works!
@ctrombley thank you! Specifying the accountID via the tag in the data source does indeed work-around the issue. Looking forward to the official fix.
Most helpful comment
@ctrombley thank you! Specifying the accountID via the tag in the data source does indeed work-around the issue. Looking forward to the official fix.