Idempotence in "instana_alerting_config" only with priorities/event_filter_event_types in alphabetical order

[ppuschmann]

There's a difference between writing

resource "instana_alerting_config" "my_resource" {
  alert_name               = "my-resource-alert"
  integration_ids          = ["${instana_alerting_channel_slack.alert_channel_in_slack.id}"]
  event_filter_query       = "entity.application.id:\"${instana_application_config.application_all.id}\""
  event_filter_event_types = ["critical", "incident", "warning"]
}

and

resource "instana_alerting_config" "my_ressource" {
  alert_name               = "my-ressource-alert"
  integration_ids          = ["${instana_alerting_channel_slack.alert_channel_in_slack.id}"]
  event_filter_query       = "entity.application.id:\"${instana_application_config.application_all.id}\""
  event_filter_event_types = ["incident", "critical", "warning"]
}

If written in the "human"-order of descending priorities / event_filter_event_types, you'd constantly get some changes on a terraform apply:

  # instana_alerting_config.alerting_eCom_general will be updated in-place
  ~ resource "instana_alerting_config" "my_resource" {
        alert_name               = "my-resource-alert"
      ~ event_filter_event_types = [
          - "critical",
            "incident",
          + "critical",
            "warning",
        ]
        event_filter_query       = "***************"
        event_filter_rule_ids    = []
        full_alert_name          = " my-resource-alert (TF)"
        id                       = "***************"
        integration_ids          = [
            "***************",
        ]
    }

If the priorities / event_filter_event_types are defined in alphabetical order, there will be no change.

This issue has only low priority.

[gessnerfl]

The root cause of this issue is the terraform data type. The data is stored in a list which is ordered. As we update the state is updated with the data coming from instana api, the order might change if instana is not returning the exact same order.
In contrast to this a set is an unordered list where items cannot be appear multiple times. This seems to be the better option in this case. I would expect a similar issue with the rule ids.

As an alternative the data type could be kept but the state is not getting updated with the data coming from instana. The only benefit of this approach would be to avoid a state migration. However I think changing the data type is the better approach.

[gessnerfl]

The issue applies to the following resources:

• alerting channel email
  • emails
• alerting-channel-webhoook
  • urls
• alerting-config
  • integration ids
  • event types
  • rule ids
• all custom event specifications (See also Downstream integration Ids not supported anymore for Custom Event #44 )
  • integration ids

For all of them, the items should be unique and Instana API might change the order. This exactly matches to the set behaviour of terraform (see also https://www.terraform.io/docs/extend/schemas/schema-types.html)

[gessnerfl]

@ppuschmann I provided a new version 0.8.2. This version should fix the issue for all the resources mentioned above including the alerting config. Can you please cross check

[ppuschmann]

I need some time for this, but will come back to you.

[ppuschmann]

I did check: It works!
Thank you very much for this improvement.