BetterStackHQ/terraform-provider-better-uptime

betteruptime_monitor - monitor_type expected_status_code is missing

Closed this issue · 11 comments

simonrozsival commented

It's possible to configure a monitor with expected status codes via the web page.

original issue: BetterStackHQ/deprecated-terraform-provider-betteruptime#7

hydrapolic commented

This was added in ce3496b

However if configured, terraform wants to update in-place the resource each time it's run even if there is no change.

adikus commented

Closing this, as the issues with expected_status_code should be now fixed on the API side.

hydrapolic commented

@adikus, just tested and still the same issue.

adikus commented

@hydrapolic which version of the plugin are you using? I just tested this with the latest one, and creating / updating a monitor with an expected_status_code worked as I would expect.

If you're on the latest version (0.3.8), could you please share your terraform config at hello@betteruptime.com so that we can have a look?

hydrapolic commented

@adikus I'm using version 0.3.8.

When issuing terraform plan, it's stated that the monitors will be updated in place. Of course there's nothing wrong with it, but in fact the value of expected_status_codes haven't changed at all so it should state "no change".

hydrapolic commented

Just checked the output again. It seems like it only happens for monitors that had expected_status_codes defined previously but then we turned it off (for example we started monitoring a service that returned 404 for url /, but later it was changed to 200 so expected_status_codes was unnecessary).

hydrapolic commented

How to reproduce:

  1. set up a monitor with monitor_type = expected_status_code and fill in expected_status_codes (for example 200/404)
  2. change monitor_type to status
# terraform apply
  # monitor will be updated in-place
  ~ resource "betteruptime_monitor" "monitor" {
      ~ expected_status_codes = [
          - 200,
          - 404,
        ]
      ~ monitor_type          = "expected_status_code" -> "status"

terraform apply
  # monitor.monitor will be updated in-place
  ~ resource "betteruptime_monitor" "monitor" {
      ~ expected_status_codes = [
          - 200,
          - 404,
        ]
        # (21 unchanged attributes hidden)
    }
adikus commented

@hydrapolic Thanks for the instructions on how to reproduce. Looks like we're not allowing for the expected status codes to be unset once they've been set. I'll have a look into that.

In the meantime it sounds like the workaround, if I can call it that, is to keep some status code in there (e.g. [200]), even if it's not going to be used.

hydrapolic commented

An alternative to that is to ignore changes in expected_status_codes once they are applied:

lifecycle {
  ignore_changes = [
    expected_status_codes
   ]
}
adikus commented

@hydrapolic We rolled out a change to the API, so when you completely remove expected_status_codes it will get correctly propagated.

hydrapolic commented

@adikus works like a charm, thanks!

  • ❤️2