Add a new resources for Anomaly Detection in Opendistro

[yardbirdsax]

I would love to see this provider enabled to create and manage resources around Anomaly Detection, namely a Detector. I would imagine the resource might look something like this.

resource elasticsearch_opendistro_detector detector {
  name = "detector"
  description = "something"
  body = <<EOT
{
  "time_field":"@t",
  "indices":[
    "index-*"
  ],
  "filter_query":{
    "bool" : {
        "filter" : [
          {
            "prefix" : {
              "log_group" : {
                "value" : "group",
                "boost" : 1.0
              }
            }
          }
        ],
        "adjust_pure_negative" : true,
        "boost" : 1.0
      }
  },
  "detection_interval": {
    "period": {
      "interval": 5,
      "unit": "Minutes"
    },
    "window_delay": {
      "period": {
        "interval": 10,
        "unit": "Minutes"
      }
    }
  }
}
EOT
}

You could also split out the various parts of the body into different blocks / arguments, but I kept it simple since that appears to be the general pattern for the rest of the resources in this provider.

[yardbirdsax]

I may have a working solution for this, but need to test more before I submit the PR as I'm admittedly a Go newb. 😄

[phillbaker]

Hi @yardbirdsax, thanks for opening an issue, this sounds like a good idea! Looking at the docs, it seems like a regular open distro monitor is used to alert on these?

There are a couple of disadvantages to just using the name/body attributes (see https://github.com/phillbaker/terraform-provider-elasticsearch/issues/93). If possible, I'd recommend building out as many attributes as possible (see for example the xpack role resource for example). It is a lot quicker to add just the body attribute, but if we go down that route see my comment here for how we can avoid some of the issues with the body attribute.

[yardbirdsax]

Ah yes, now that I see the direction of the codebase is to move away from the "raw body" approach I agree that it'd be better to split this out (with the exception of a few places; for example the "filter_query" section is probably still best expressed as regular JSON since we don't want to get into duplicating Elasticsearch DSL in HCL). It will be more of a challenge to my fledgling Go skills but I'm up for it so long as this can take a bit longer than I thought. :)

And yes, you're correct that the regular monitor resource could be used to alert off these. The example I'd include as part of this would have that part as well.