Closed ojongerius closed 8 years ago
Interesting. I was tempted to refactor this one a little; "warning" and "critical" are both schema.Typemap
, and I know and have used schema.TypeSet
before. What I like about using a Set is that the logic is handled in the schema, and its easier to see what's going on.
Currently the schema shows:
"critical": &schema.Schema{
Type: schema.TypeMap,
Required: true,
},
In the state file that will show up like so:
"attributes": {
"critical.#": "2",
"critical.notify": "@pagerduty",
"critical.threshold": "0",
The graph resource (using Set) state:
"attributes": {
"dashboard_id": "62086",
"description": "description for graph bar",
"id": "1438859136",
"request.#": "3",
"request.2366423942.query": "avg:system.mem.user{*}",
"request.2366423942.stacked": "false",
"request.3806987567.query": "avg:system.cpu.user{*}",
"request.3806987567.stacked": "false",
Anyway, it does not matter much which way to go. They hardest problem to solve is parsing the query before saving it. Also there are 2 types of monitors; metric and check based. I've raised #7 for this one.
This will be heaps easier after upstream API changes and work in #62 and #64
Revert to one simple monitor that does all the things, versus many small different monitors that do not do all the things in #73
The monitor resource does not have read function (like
resourceDatadogMonitorRead
).Having one should be faster, though I'm guessing most win is already enjoyed by the existing Exists resource.