Add SLO support to provider

[wandergeek]

Overview

This PR adds kibana SLO management capabilities to the provider.

Testing

The custom metrics and histogram indicators are only supported in >8.10, so you will need to launch latest and greatest stack. I've been using kibana to do this:

Launch ES

	cd ~/work/kibana
	yarn kbn bootstrap
	yarn es snapshot --license trial --use-cached

Launch KB

	cd ~/work/kibana
	yarn kbn bootstrap
	yarn start --no-base-path

Run tests

export ELASTICSEARCH_ENDPOINTS=http://localhost:9200 \
KIBANA_ENDPOINT=http://localhost:5601 \
ELASTICSEARCH_USERNAME=elastic \
ELASTICSEARCH_PASSWORD=changeme

make lint test testacc docs-generate

[tobio]

Other version specific resources define a SkipFunc to avoid the failing tests.

[wandergeek]

A note from testing to deal with later:

I restarted the stack, but still had some terraform state laying around. When I tried to do an apply, I got the following:

elasticstack_kibana_slo.test_slo: Refreshing state... [id=SozILMG9RtCl6hFyeubVow/7374c7b0-21e3-11ee-bd67-4fa609eac85f]
╷
│ Error: 404 Not Found
│
│   with elasticstack_kibana_slo.test_slo,
│   on provider.tf line 25, in resource "elasticstack_kibana_slo" "test_slo":
│   25: resource "elasticstack_kibana_slo" "test_slo" {
│
╵

A 404 is expected here since obviously that SLO is gone with the restart, but wondering if the provider should be smart enough to recreate it or just fail like this? I feel like at least the error message should be a bit more specific?

[tobio]

A 404 is expected here since obviously that SLO is gone with the restart, but wondering if the provider should be smart enough to recreate it or just fail like this? I feel like at least the error message should be a bit more specific?

The resource should be treating this error as if the resource no longer exists and needs to be recreated.

[dimuon]

@wandergeek , please update CHANGELOG.md.

[dimuon]

@wandergeek , thanks for the contribution 👍
There are some nitpicks and few thoughts about adding support for 2 currently unsupported indicator types.

[wandergeek]

Using a static spec file until elastic/kibana#161922 is merged.

@wandergeek , the PR is merged. Shall we switch to getting OpenAPI specs from Kibana repo instead of using the static file?

Yep, good idea. One thing I'm grappling with right now is whether to point the URL to main or a specific commit. Ideally I'd like to point it to a particular kibana version tag, but it looks like there's a number of commits that haven't been backported for some reason.

Curious what you think here. I've pointed it to main for now.

[dimuon]

Using a static spec file until elastic/kibana#161922 is merged.

@wandergeek , the PR is merged. Shall we switch to getting OpenAPI specs from Kibana repo instead of using the static file?

Yep, good idea. One thing I'm grappling with right now is whether to point the URL to main or a specific commit. Ideally I'd like to point it to a particular kibana version tag, but it looks like there's a number of commits that haven't been backported for some reason.

Curious what you think here. I've pointed it to main for now.

I guess we can follow the same approach as for alerting.

[wandergeek]

I guess we can follow the same approach as for alerting.

This is what I'd like to do, but not all changes I want are in 8.9. I guess I could just point it at 8.10 even though its unreleased.

One thought that I had today was it'd be cool to somehow store/tag what sha the generated client is using, so when it gets updated, you can easily see what changed since the last update.

[wandergeek]

Ok, just pushed a mammoth update to this. I've broken up the indicators into their own subtypes as you suggested to work around the SDKv2 limitations. There's still a little clean up work to do, but thought I'd share so you could have a look overnight (if you have time).

[dimuon]

@wandergeek , it looks good 👍

[dimuon]

LGTM 👍