Use deterministic ordering for tags

[digitalronin]

We often see planned changes which are just the provider re-ordering the tags of our pingdom checks.

e.g. terraform plan will report something like this:

Terraform will perform the following actions:

  # pingdom_check.mycheck will be updated in-place
  ~ resource "pingdom_check" "mycheck" {
        encryption               = true
        host                     = "my.host"
        id                       = "6564539"
        integrationids           = []
        name                     = "myhost - healthcheck"
        notifyagainevery         = 0
        notifywhenbackup         = true
        port                     = 443
        probefilters             = "region:EU"
        publicreport             = true
        requestheaders           = {}
        resolution               = 1
        sendnotificationwhendown = 6
      ~ tags                     = "one,two,three" -> "three,one,two"
        teamids                  = []
        type                     = "http"
        url                      = "/ping"
        userids                  = []
    }

Plan: 0 to add, 1 to change, 0 to destroy.

This doesn't do any harm, but it means any scripts we have which check to see if terraform reports that changes have to be made often generate false positives.

We don't always see this. I'm guessing that's because the tag order is arbitrary, and sometimes the order just happens to match the order which exists in the terraform state.

If possible, it would be great if the order of tags could be made deterministic, so that we don't see these null changes reported in terraform plan.

We're using release 1.1.1 of the provider.

[alakiikonen]

There is already a long living MR opened for the issue, https://github.com/russellcardullo/terraform-provider-pingdom/pull/46 . @saj do you have a take on what is going to happen to that, should it be merged at some point, or just closed?

[saj]

Reading through that open MoJ issue brought back a lot of memories... :)

It is not my place to say whether #46 should be merged. I found that patch to be essential -- I was not able to effectively manage our Pingdom resources without it -- but I can understand not wanting to break backwards compat for existing users. We were using our own build of this plugin, forked with that patch. (We are no longer using Pingdom. If we were to go back, I'd need that patch again.)