inkel
commented
2 years ago Hi @bnjns! Thanks for taking interest in this provider.
First and foremost: this is a personal opinion and doesn't reflect in any way those of Grafana Labs. I love this idea, and I've even thought about it in the past. The benefits you mention as well the painful current experience provides are definitely true. However, having parity with the JSON used by grafana could prove harder to maintain.
One alternative that I'd like to mention for easily maintaining the JSON source and facilitating reviewing changes is using Grafonnet, a Jsonnet library that allows you to declare your dashboards in a simpler way; check the examples for more information.
This doesn't mean that I don't consider this as a good feature to have, although we would need to review this and prioritize it before starting with any work.
Thanks again!
bnjns
justinTM
sdboyer
sidekick-eimantas
julienduchesne
bengesoff
I appreciate that this is a potentially controversial thing to raise, likely to spark debate, and will be a fair chunk of work but I'm starting to get our Grafana configuration into version control using the terraform provider, and as someone who uses Terraform a lot, the current way of configuring dashboards is proving to be somewhat painful, and difficult for those less familiar with the JSON syntax to review.
While the use of
config_jsonto simply provide the raw JSON makes it easy to copy/paste from an existing dashboard, it doesn't really follow Terraform's concept of being a declarative configuration language. I think it would be much better if dashboards were configured with arguments and blocks, as this would allow you to take advantage of the full power of Terraform (using things like dynamic blocks to iterate or enable/disable panels); to be able to achieve this with the current implementation, you have to use template interpolation and/or some hackyjsonencoded variables, which (being invalid JSON) would break any editor that you use to maintain the dashboard config.I also believe that this approach would allow the provider/API to abstract away the default values, resulting in a much smaller and more maintainable config. It would also make it easier to reference other resources/data sources in the config, as you'd see the reference at the site where it's used.
Here's example of how using blocks and arguments can be an improvement over simple JSON
Using config_json
```hcl resource "grafana_dashboard" "example" { config_json = <Using blocks and arguments (not a fixed structure, just an example)
```hcl resource "grafana_dashboard" "example" { title = "Example Dashboard" editable = true style = "dark" // Could make use of a default for this time { from = "now-24h" to = "now" } timepicker { refresh_intervals = ["1m", "5m", "15m", "30m", "1h"] } template_variable { // this is empty here, but templating would also be very powerful using blocks } panel { type = "logs" datasource = grafana_data_source.cloudwatch.name title = "Warnings and Errors" grid_position = { h = 11 w = 15 } target { ref_id = "A" query_mode = "Logs" expression = "fields @message\n| filter @message like /level=(warn|error)/\n| sort @timestamp desc" log_group_names = ["/ecs/example-service"] } } panel { type = "graph" datasource = grafana_data_source.cloudwatch.name title = "Log Errors" grid_position = { h = 11 w = 9 x = 15 y = 0 } bars = true fill = 1 fill_gradient = 0 null_point_mode = "null as zero" // This would probably be better as a series of enums - NULL_AS_ZERO yaxis = { align = false align_level = null } target { ref_id = "A" query_mode = "Logs" expression = "filter @message like /level=(error)/\n| stats count (*) as Error by bin(1m)" log_group_names = ["/ecs/example-service"] stats_groups = ["bin(1m)"] } threshold { color_mode = "critical" fill = true line = true op = "gt" value = 0 } // We would probably be able to default to 1 x-axis and 1 y-axis so you'd only need these to override the default config axis { type = "x" mode = "time" } axis { type = "y" format = "short" decimals = 0 min = 0 } legend { show = true } tooltip { shared = true value_type = "individual" } alert { name = "Log Error" for = "5m" frequency = "1m" tags = {} execution_error_state = "alerting" no_data_state = "ok" condition { type = "query" params = ["A", "5m", "now-1m"] operator = { type = "and" } reducer = { type = "avg" } evaluator = { type = "gt" params = [0] } } notification { uid = grafana_alert_notification.example.uid } } } } ```In terms of implementation, I think this can be done in a fairly generic way that simply takes the HCL syntax and converts it into the equivalent JSON. For the most part, the argument structure would match the JSON, with either blocks or maps for nested objects and blocks for generating lists. Ultimately all this needs to do is generate the JSON, which it then sends to the API as per the current implementation.
While I haven't written a provider myself, I have reasonable experience with Go and Terraform parsing so would be more than happy to directly contribute to this.