[ResponseOps] Maintenance Window Resource

[adcoelho]

Closes #197021

Summary

The response-ops team has been working on a public maintenance window API.

Most of the work is done and the feature should be available for v9.1.0. (Feature branch PR)

This PR enables users to define maintenance windows tf resources.

Testing

The server version needs to be >=9.1.0 so on all the tests I have been using the maintenance window API feature branch.

I built it locally and ran testacc or Terraform commands.

What would the proper procedure be to deploy this change?

Example resource

resource "elasticstack_kibana_maintenance_window" "my_maintenance_window" {
  title   = "Terraform Maintenance Window Updated"
  enabled = true
  custom_schedule {
    start    = "1992-01-01T05:00:00.200Z"
    duration = "12d"

    recurring {
      every       = "20d"
      end         = "2029-05-17T05:05:00.000Z"
      on_week_day = ["MO", "TU"]
    }
  }

  scope {
    alerting {
      kql = "_id: '1234'"
    }
  }
}

[jcger]

seems like this wasn't generated but implemented by you. If so, couldn't this be generated based on the OAS files we create on the Kibana side?

[adcoelho]

The generation is only for the API client, so the resource specification is usually done manually. Maybe there is a way but I don't think we use it in this project.

[tobio]

Hashicorp have an openapi generator which builds a schema based on a set of openapi routes. It's not used in this project yet, but we're using it to help with Serverless project resources. It's... ok, but has some limitations to deal with.

[tobio]

Are we able to use the consolidated kibana spec for this new resource rather than on the older alerting client?

[tobio]

Can we rebuild this as a plugin-framework based resource (data view as an example). It automatically solves a bunch of TF related limitations, and should be the future for any new work in the provider.

[tobio]

Hashicorp have an openapi generator which builds a schema based on a set of openapi routes. It's not used in this project yet, but we're using it to help with Serverless project resources. It's... ok, but has some limitations to deal with.