terraform-provider-newrelic
terraform-provider-newrelic copied to clipboard
Creating a new `newrelic_synthetics_script_monitor` fails Terraform with too many public locations.
Hi there,
Thank you for opening an issue. In order to better assist you with your issue, we kindly ask to follow the template format and instructions. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests only. General usage questions submitted as issues will be closed and redirected to New Relic's Explorers Hub https://discuss.newrelic.com/c/build-on-new-relic/developer-toolkit.
Please include the following with your bug report
:warning: Important: Failure to include the following, such as omitting the Terraform configuration in question, may delay resolving the issue.
- [ ] Your New Relic
provider
configuration (sensitive details redacted) - [x ] A list of affected resources and/or data sources
- [ ] 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
Run terraform -v
to show the version. If you are not running the latest version of Terraform, please upgrade because your issue may have already been fixed.
Terraform v0.14.3
Your version of Terraform is out of date! The latest version
is 1.2.9. You can update by downloading from https://www.terraform.io/downloads.html
Yes, it's an outdated version of Terraform, but no, upgrading won't fix the issue. The issue is with how the provider handles a certain type of error returned from the NerdGraph API.
Affected Resource(s)
Please list the resources as a list, for example:
-
newrelic_synthetics_script_monitor
If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.
Terraform Configuration
Please include your
provider
configuration (sensitive details redacted) as well as the configuration of the resources and/or data sources related to the bug report.
Unfortunately, I cannot provide an example HCL configuration, but the gist of one would look like
resource "newrelic_synthetics_script_monitor" "appliance" {
name = "Synthetic"
type = "SCRIPT_API"
period = "EVERY_5_MINUTES"
status = "ENABLED"
locations_public = [
"AP_EAST_1", // Hong Kong
"AP_SOUTH_1", // Mumbai
"AP_SOUTHEAST_1", // Singapore
"AP_NORTHEAST_2", // Seoul
"AP_NORTHEAST_1", // Tokyo
"AP_SOUTHEAST_2", // Sydney
"US_WEST_1", // San Francisco
"US_WEST_2", // Portland
"US_EAST_2", // Columbus
"US_EAST_1", // Washington
"CA_CENTRAL_1", // Montreal
"SA_EAST_1", // São Paulo
"EU_WEST_1", // Dublin
"EU_WEST_2", // London
"EU_WEST_3", // Paris
"EU_CENTRAL_1", // Frankfurt
"EU_NORTH_1", // Stockholm
"EU_SOUTH_1", // Milan
"ME_SOUTH_1", // Manama (Bahrain)
"AF_SOUTH_1", // Cape Town (South Africa)
]
script = templatefile(
"${path.module}/script.tpl",
{}
)
script_language = "JAVASCRIPT"
runtime_type = "NODE_API"
runtime_type_version = "16.10"
}
Actual Behavior
The newrelic_synthetics_script_monitor.appliance
resource fails Terraform with an Error: BAD_REQUEST: Monitor name already exists.
. This is the case even when a monitor with the name absolutely did not exist prior to running Terraform. Additionally, the monitor does successfully create.
The first call to create the monitor returns
---[ RESPONSE ]--------------------------------------
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Cache-Control: max-age=0, private, must-revalidate
Content-Security-Policy: frame-ancestors *.newrelic.com
Content-Type: application/json; charset=utf-8
Date: Tue, 30 Aug 2022 20:38:23 GMT
Proxied-By: Service Gateway
Served-By: nerd-graph
Server: Cowboy
Strict-Transport-Security: max-age=31536000; includeSubDomains
e4
{
"data": {
"syntheticsCreateScriptApiMonitor": null
},
"errors": [
{
"extensions": {
"errorClass": "TIMEOUT"
},
"locations": [
{
"column": 5,
"line": 4
}
],
"message": "Resolution of this field timed out",
"path": [
"syntheticsCreateScriptApiMonitor"
]
}
]
}
0
-----------------------------------------------------: timestamp=2022-08-30T15:38:24.533-0500
even though the monitor is created.
The provider then tries to create monitor again, and gets a conflict.
Expected Behavior
Terraform should not have failed, because the monitor was created. Instead, upon receiving this timeout error, it should check if the monitor creation was actually successful and if so, populate the resource into the state file.
Steps to Reproduce
Please list the steps required to reproduce the issue, for example:
- Create a configuration that will create a new synthetic script monitor using all of the public locations
- Apply the configuration
Debug Output
Please see the above snippet from a Terraform trace log.
Hi @zeffron, thanks for raising the issue. We will prioritise the issue.
Hi @zeffron, It is a known issue and the API team are currently working on it.
Is there an ETA for when this will be resolved? We're now encountering this issue when using only public location. The Terraform provider should not be relying on a fix from the API. It should be able to gracefully handle API errors.
There's not much we can do on the Terraform side if the API is broken.
Disagree. I included an explanation of what Terraform can do to work around this in my original description:
It should check if the monitor creation was actually successful and if so, populate the resource into the state file.
The error is specific enough to allow for this, as it's a timeout error returned by the API, not an HTTP or TCP timeout.
@zeffron The API team has taken this up and is implementing a solution. The problem also existed in the UI and we generally don't like working around API issues on the Terraform side.
There's a fix out in production. Can someone try to reproduce?
I continue to reproduce the issue with 100% reliability. Even after upgrading to 3.4.4 of the provider just in case.
Thanks @zeffron
Version 3.8.0 still has this issue.
Hi, We recently had some improvements wrt. Synthetics, could someone please try to re-verify with the latest version (3.20.1) and confirm it's working as expected ?
I still see this issue with (3.20.1)
Hi, Thanks for confirming, we're checking with the API team to investigate further and this will be addressed based on the priority. Thank you !
Still seeing this issue with newrelic/newrelic v3.27.1. Is there any workaround for this issue?
hi we are still investigating this issue