New Relic migration from 1.X to 2.X

With reference to the below :

Could you please confirm the parameters that are mandatory for the New Relic provider 2.X.

Also, in the above post we do not see the region to be mentioned. Although it’s mentioned on the documentation page for new relic provider

In our case it works both the ways with/without the region as well.

Earlier it used to fail with a 403 response for some of the services which seems to have been resolved automatically now. Could you please clarify if that’s something related to the migration or New Relic itself.

We ran the terraform plan with TRACE ON by which we got 403 errors for different services every time we ran the build and sometimes it builds successfully without any errors at all.

Please suggest on the same. Thanks.

any update on this??

Hi @Bikash.Singh,

Sorry you’re running into these issues. At first glance, this sounds like a Personal API Key vs Admin API Key issue, or potentially a region and/or cross-account issue.

If you’ve already been through our v2 migration guide (it sounds like you have) and are still having this problem, then my immediate hunch is that the account ID and Personal API Key are in a cross-account scenario where user role/permissions might be causing an issue. We’ll want to ensure your API keys being referenced fall within the account ID being used.

If your Terraform runs only fail intermittently, then something could be going on with an upstream API, but 403s indicate a permissions issue. Are you trying to use multiple accounts in your configuration?

Generally speaking, the following bullet points have resolved this scenario for several customers.

  • Your Personal API Key (usually starts with NRAK-) can now be considered your main API key. Use your Personal API Key (NRAK-) to set the api_key attribute in the provider configuration.

  • Your Admin API Key (usually starts with NRAA-) is required to provision Synthetics resources and Infrastructure Alert Conditions resources. All other resources can be managed with your Personal API Key. Use your Admin API Key (NRAA-) to set the admin_api_key attribute in the provider configuration.

  • The region attribute of the provider configuration is required and must be set to “US” or “EU”.

  • Use API keys that fall under associated account ID

(Note: You can use environment variables as well to set these attributes under the hood.)

If we’re still having issues after double checking all of the above, we’ll probably need to see your provider configuration (sensitive data redacted) to do some further debugging, but hopefully this helps. :slight_smile:

1 Like

Hi @sblue

Thanks for the detailed response above. Much appreciated.
As you said at first it seemed like a Personal/Admin API key issue, we cross checked that along with the role and permission for the keys and can confirm that the API keys being referenced fall within the account ID being used.

No, at the moment we are just running it on only one account.

Double checked on all of the above suggestions but still the inconsistency with the builds remains.

One more thing to add here is that the above change has s3(with locking via DynamoDB) enabled, but when we disable that, the terraform plan runs smoothly. This approach however might not be considered as a migration as that would be a fresh start with 2.X provider.

A similar post was made containing the trace logs for the terraform plan.

any update?
It seems a similar issue is already opened.

Hi Team,
Is there any update on the above issue. It still seems to be an on-going issue.

@sblue Any updates or suggestions for this? Anything that we can try out from our end which may help in figuring out this issue faster and thus lead to a quicker resolution?

Hi @siddhant.agarwal, it looks like you’ve been working with my colleague today. Let’s continue the discussion in the open GitHub issue #881 so we have a centralized location to follow along. :slightly_smiling_face: