Dashboard support - future of newrelic_one_dashboard and newrelic_one_dashboard_raw

[kidk]

Hi everyone 👋

If you haven't seen it already we recently added support for dashboard json: https://registry.terraform.io/providers/newrelic/newrelic/latest/docs/resources/one_dashboard_json

It allows you to provide a json file or template to manage a dashboard in New Relic.

resource "newrelic_one_dashboard_json" "foo" {
   json = file("dashboard.json")
}

resource "newrelic_one_dashboard_json" "foo" {
   json = templatefile("dashboard1.json", {
      account_id = 1234
   })
}

Because we are sending the raw JSON back to the API it allows you to use the latest dashboard features like y-axis configuration, variables (soon), color selection (soon), and others.

This brings us to an important question: What do we do with newrelic_one_dashboard and newrelic_one_dashboard_raw? Long term these resources are always going to be behind on features compared to the newrelic_one_dashboard_json because each new feature for newrelic_one_dashboard and newrelic_one_dashboard_raw requires custom implementation on the Terraform side, where newrelic_one_dashboard_json will usually just work, or in worst case needs an automated code generation run.

That's why I'm thinking to add a deprecation warning to newrelic_one_dashboard and newrelic_one_dashboard_raw and point everyone towards newrelic_one_dashboard_json. Long term (1/2 years) we would remove the newrelic_one_dashboard and newrelic_one_dashboard_raw resources.

What do you all think? Does this make sense to you, or are am I forgetting certain use-cases?

Thanks a lot

[rdhar]

That's a neat approach and it totally works around any differences between the latest dashboard features and Terraform's implementation of it.

Documentation-wise, it might be worth including some examples of templating so it's easier for users to onboard and starting (re-)using newrelic_one_dashboard_json for multiple NR accounts. While it'd been great to have client-side validation of dashboard fields/attributes, this still seems like the best compromise.

[kidk]

Great feedback @rdhar I'm going to add some examples.

[donald-m-ritter]

I do have a concern with removing newrelic_one_dashboard. I'm using the provider to build dashboards to monitor multiple internal company APIs. I've got an extra validation step that uses terraform plan and terraform show --json to show the differences between the current state and the expected state to be applied to validate that nothing was changed at a later date. To avoid some internal maintenance headaches I build the state file every time by importing using the dashboards guid.

newrelic_one_dashboard will import itself, pages, and widgets into the local state. Unfortunately newrelic_one_dashboard_json won't import that data and doesn't seem to be able to download the dashboards json.

If you remove newrelic_one_dashboard I'd be losing that import-ability unless newrelic_one_dashboard_json can gets it's json imported as well.

[kidk]

Thanks @donald-m-ritter I appreciate you taking the time to write this down.

I agree this is a limitation that needs to be resolved before we start thinking about removing the other resources.

[kidk]

To give an update here: We are going to continue our support for newrelic_one_dashboard and newrelic_one_dashboard_json.

[donald-m-ritter]

Thank you for taking our use case into consideration and continuing to support it.