Allow default alert contact to be configured

[aequitas]

• Convert alert contact ID to string (it can be 0 padded number)
• Add alert contact datasource
• Extend example configuration with default alert contact

TODO:

• Pagination
• Migration code for int to string conversion alert contact id
• Tests

[drubin]

Thanks for this I would love to use this as well.

Just a few questions :)

[aequitas]

I added a configuration example of what I think this will look like when fully implemented. I'll look into the pagination stuff as well.

[aequitas]

The latest commit is a working example. I still need to add pagination support.

I had to convert the alert contact ID from int to string as the value can be a zero padded number and the correct alert contact will not be found without those zero's. Maybe this applies to the other resources as well? Also I have not tested this with an existing configuration so migration code might need to be added as well.

[aequitas]

So as far as I can tell there is no reason for migration, as Terraform stored the ID's as strings in the state file. So by reading them as string instead of int in the new code they are automatically read correctly.

[leeif]

The alertcontact["id"] here seems to be a float64 type which can't be converted by .(string).

[aequitas]

According to the API documentation the ID is a string https://uptimerobot.com/api

I stumbled upon this because one of the ID's generated for me by the API started with a 0 which would be stripped when converting form a string to a int/float64 and thus Terraform would record an invalid ID in the state file.

[leeif]

May be this is a uptimerobot issue. At least for me, the response of this API is different from the document.
https://gist.github.com/leeif/0bc4eb5f9ca03b9c487169d98167cc40

[aequitas]

I think this is an issue at UR's end.

Alert contact create returns a integer:

$ curl -sS -X POST -H "Cache-Control: no-cache" -H "Content-Type: application/x-www-form-urlencoded" -d "api_key=XXXX&format=json&friendly_name=Test2&type=2&value=test2%40example.com"  "https://api.uptimerobot.com/v2/newAlertContact"|jq .
{
  "stat": "ok",
  "alertcontact": {
    "id": 2809628
  }
}

While getAlertContacts returns a string:

$ curl -sS -X POST -H "Cache-Control: no-cache" -H "Content-Type: application/x-www-form-urlencoded" -d "api_key=XXXXXX&format=json"  "https://api.uptimerobot.com/v2/getAlertContacts"|jq .
{
  "stat": "ok",
  "offset": 0,
  "limit": 50,
  "total": 3,
  "alert_contacts": [
    {
      "id": "0717807",
      "friendly_name": "[email protected]",
      "type": 2,
      "status": 2,
      "value": "[email protected]"
    },
    {
      "id": "2806958",
      "friendly_name": "Test",
      "type": 2,
      "status": 0,
      "value": "[email protected]"
    },
    {
      "id": "2809628",
      "friendly_name": "Test2",
      "type": 2,
      "status": 0,
      "value": "[email protected]"
    }
  ]
}

One thing I do notice is that the ID of the default alert contact starts with 0 but the others are in a completely different number range.

[aequitas]

Also querying without the zero does not work:

$ curl -sS -X POST -H "Cache-Control: no-cache" -H "Content-Type: application/x-www-form-urlencoded" -d "api_key=XXXXX&format=json&alert_contacts=717807"  "https://api.uptimerobot.com/v2/getAlertContacts"|jq .
{
  "stat": "fail",
  "error": {
    "type": "not_found",
    "message": "Alert Contact(id: 717807) not found."
  }
}

$ curl -sS -X POST -H "Cache-Control: no-cache" -H "Content-Type: application/x-www-form-urlencoded" -d "api_key=XXXXX&format=json&alert_contacts=0717807"  "https://api.uptimerobot.com/v2/getAlertContacts"|jq .
{
  "stat": "ok",
  "offset": 0,
  "limit": 50,
  "total": 1,
  "alert_contacts": [
    {
      "id": "0717807",
      "friendly_name": "[email protected]",
      "type": 2,
      "status": 2,
      "value": "[email protected]"
    }
  ]
}

[aequitas]

So I added a conversion to string instead of casting. I don't think UR will change their API and break all clients out there (didn't attempt to contact them though). But this should cover both cases:

• in newAlertContact where the ID is returned as a integer
• in all other cases where it is handled as a string

Also only the response values are types (due to JSON) and the request values not (as they are HTTP parameters).

[louy]

Nice work @aequitas!

Is this ready to be merged? Do you still want to add a test?

[aequitas]

@louy I added a test and fixed some bugs I found when running the other acceptance tests. I also did a small testrun 'converting' a configuration created using the latest master to one with this branch and found no issues. So afaict this now works as expected and can be merged.