Screenboards unable to export
Opened this issue · 10 comments
Timeboards seemed to export fine, though without the query part of it.
The problem is when exporting screenboards I get an error:
$ DATADOG_API_KEY=XXX DATADOG_APP_KEY=XXX ./dd2tf screenboards --ids 123
FATA[0000] json: cannot unmarshal string into Go struct field Screenboard.width of type int
Usage: ./dd2tf <subcommand> <subcommand_options>
where <subcommand> is one of: []
Environment variables DATADOG_API_KEY and DATADOG_APP_KEY are required
keys and id changed
I have built from master and the tagged version, same result.
Is something missing? The only thing that is not completely normal is this message during the install:
$ dep ensure
Warning: the following project(s) have [[constraint]] stanzas in Gopkg.toml:
✗ gopkg.in/zorkian/go-datadog-api.v2
However, these projects are not direct dependencies of the current project:
they are not imported in any .go files, nor are they in the 'required' list in
Gopkg.toml. Dep only applies [[constraint]] rules to direct dependencies, so
these rules will have no effect.
Either import/require packages from these projects so that they become direct
dependencies, or convert each [[constraint]] to an [[override]] to enforce rules
on these projects, if they happen to be transitive dependencies.
Sys info:
Linux thlarsen 4.18.0-18-generic #19-Ubuntu SMP Tue Apr 2 18:13:16 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Distributor ID: Ubuntu
Description: Ubuntu 18.10
Release: 18.10
Codename: cosmic
go version go1.12.5 linux/amd64
@thomasfinstad sorry for late reply!
dep ensure issue is most likely not related - this is a leftover from previous commit (but thanks for pointing anyway!).
Second (and main) issue is interesting. I actually have no Screenboard.width as a toplevel properties in template, so they should be ignored. I will check tomorrow, once I have access to Dadadog.
I faced some issue importing screenboards too. I will try to get some time to investigate it too.
Same here. Seeing
FATA[0000] json: cannot unmarshal string into Go struct field Screenboard.width of type int
Aside dd2tf is a great tool - thanks for building!
Sorry guys, I was extremely busy recently. The issue seems to be related to zorkian/go-datadog-api#192, although I'm not sure. Will try to check this week.
This issue is most likely related to the updated "new_id" that Datadog is using - it is a alphanumeric value rather than simply numeric
I forked this repo and the zorkian/go-datadog-api repo and adjusted the unmarshall so that it ignores width. This works, but some formatting is lost.
I think the bigger issue is that Datadog is moving away from screenboards & timeboards in favor of one unified dashboard.
Release notes as of two days ago
datadog_dashboard: New Resource combining screenboard and timeboard, allowing a single config to manage all of your Datadog Dashboards. (#249)
Think you have time to build this out for the new resource type? I'd be happy to offer some help.
@mlindes first of all, thanks for the investigation.
I can spend time to build new resource, but I recently stumbled across terraformer. So I'm not even sure developing dd2tf makes any sense :D.
Hey @amnk sorry for the slow reply.. And thanks or yours!
I wasn't aware of Terraformer, but have since been trying to make it work for me. Now with Terraformer's master build (hash 75ba185), Terraform v0.12, Datadog tf provider 2.4.0, and zorkian's 2.24.0 build, Terraformer will generate a tfstate file, which is nice, but not quite fitting my use case. Maybe not yours too?
I'd like to be able to export a board into a standard tf config file so that I can then manipulate that file by iterating over a query, for example. Or simply to keep my monitors stored as code so that any adjustments to thresholds are logged and applied with a deploy.. There are others, but this is a brief idea.
Anyhow, where this is leading.. I'm revisiting the path of my last question.. any thoughts to continue back on this project? Or... maybe I should look more into converting a state file... or..
@mlindes if this project is useful to someone - I will continue it :)
Will try to allocate time today to fix this issue.
@amnk for what it's worth, with some recent pr's merged in to the Terraformer project, I can accomplish what I'm looking for - .tf files export for most resources.
That said, this dd2tf tool is more friendly to work with.
@mlindes thanks for honest feedback.
When I initially coded this - I was also not aware of Terraformer (or maybe it did not exist - not sure). But their approach to this problem is much more advanced than what I do here... and much more professional :)
I will try to port this tool to new API, and maybe even adopt a smarter way to generate files instead of simple hand crafted templates... But I'm not sure about timeline to be honest. That might take some time, maybe a week or two (yeah, I know I was silent on current issues for waaay more time).
By the way, how exactly dd2tf is more friendly? Is that because of narrow scope?