#373 (v0.6.22) has broken our deployment of opsgenie_api_integration

[glenthomas]

Terraform Version

v1.4.6

Affected Resource(s)

• opsgenie_api_integration

Terraform Configuration Files

Getting the Terraform HCL configuration is not easy as we are using modules. Hopefully the plan output will be helpful enough:

  ~ resource "opsgenie_api_integration" "this" {
        id                             = "d5f5bb13-93Je-402e-b663-j37as487a632c"
      ~ ignore_responders_from_payload = true -> false
        name                           = "A CloudWatch Integration"
      ~ owner_team_id                  = "******************************************************************************"
        # (5 unchanged attributes hidden)

      - responders {
          - id   = "85d62o123-3f9f-83jt-b0bb-c60e9dbac825" -> null
          - type = "team" -> null
        }
    }

  ~ resource "opsgenie_integration_action" "prepend_environment" {
        id             = "d5f5bb13-93Je-402e-b663-j37as487a632c"
        # (1 unchanged attribute hidden)

      ~ create {
          ~ ignore_responders_from_payload       = true -> false
            name                                 = "Prepend environment"
            tags                                 = []
            # (16 unchanged attributes hidden)

          - responders {
              - id   = "a40626e0-p735-439e-936b-926510409643" -> null
              - type = "team" -> null
            }

            # (1 unchanged block hidden)
        }

        # (1 unchanged block hidden)
    }

Output

Error: Error occurred with Status code: 422, Message: A CloudWatch Integration is assigned to team [85d62o123-3f9f-83jt-b0bb-c60e9dbac825], responders field must contain [85d62o123-3f9f-83jt-b0bb-c60e9dbac825] and no other., Took: 0.120000, RequestId: t8e8d80b-fd3e-4791-9cfd-72606bc58f6w

  with opsgenie_api_integration.this,
  on /tmp/terraform-data-dir/main.tf line 1, in resource "opsgenie_api_integration" "this":
   1: resource "opsgenie_api_integration" "this" {

Expected Behavior

It worked ok on previous versions.

Actual Behavior

It failed with 422 status code error

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply

Important Factoids

Are there anything atypical about your accounts that we should know? For example: Running in EC2 Classic? Custom version of OpenStack? Tight ACLs?

References

• 373

[Dekunite]

Hi @glenthomas, I'm trying to find the root cause by trial and error since we only have the diff/plan output. I think "opsgenie_api_integration" is the cloudwatch integration mentioned in the error log right? I wasn't able to replicate it yet

I couldn't reason the ` ~ owner_team_id = "**"

(5 unchanged attributes hidden)

  - responders {
      - id   = "85d62o123-3f9f-83jt-b0bb-c60e9dbac825" -> null
      - type = "team" -> null
    }`

part. Did you put the "*****" in owner team or is it a parsing issue or something? Would be great if you could find the configuration.

Current status of the integration could also be useful from https://docs.opsgenie.com/docs/integration-api#get-integration

[glenthomas]

Hello @Dekunite, I think the owner_team_id is being masked by Terraform or GitHub Actions.

Here is the current state of the integration, queried via the API.

{
   "data":{
      "_readOnly":[
         "isAdvanced",
         "isGlobal"
      ],
      "advanced":true,
      "enabled":true,
      "id":"d5f5bb13-880c-4e02-66b3-b927487a809c",
      "allowConfigurationAccess":false,
      "allowDeleteAccess":true,
      "allowReadAccess":true,
      "allowWriteAccess":true,
      "assignedTeam":{
         "id":"a26e0406-209e-439e-936b-638492405844",
         "name":"Yard Management App support team"
      },
      "customPriority":"",
      "extraProperties":{},
      "ignoreExtraPropertiesFromPayload":false,
      "ignoreRecipientsFromPayload":false,
      "ignoreRespondersFromPayload":false,
      "ignoreTagsFromPayload":false,
      "ignoreTeamsFromPayload":false,
      "isAdvanced":true,
      "priority":"",
      "recipients":[],
      "responders":[],
      "suppressNotifications":false,
      "tags":[],
      "isGlobal":false,
      "maintenanceSources":[],
      "name":"Yard Management App - CloudWatch Integration - [prod]",
      "ownerTeam":{
         "id":"a26e0406-209e-439e-936b-638492405844",
         "name":"Yard Management App support team"
      },
      "type":"CloudWatch"
   },
   "took":0.09,
   "requestId":"d63aca76-1d72-b5e4-4e7f-d71afb5c4cdc"
}

[Dekunite]

Hi again @glenthomas , this was very challenging to recreate. The problem starts when an integration action is added to an integration.

• integration_action wasn't updating responders properly. This should be fixed with 0.6.23
• When an integration_action is added integration_action responders takes priority so if there is a "owner_team_id" in integration. The same owner team should also be present in the integration_action "responders"

• Updating an integration via the API doesn't update the integration_action as of now. I've contacted Integration team about this they will investigate. If you create a support ticket about this in Atlassian it could shorten the investigation time. For now to overcome this you can update integration_action first then update the integration using terraform. Or you can just create the integration and integration_action from scratch.(Changing owner team once from the UI can also fix it)

  FYI: If you encounter an error like "keep original responders[true] should be equal to false,", you should set "ignore_responders_from_payload" boolean manually.

  The responders in https://docs.opsgenie.com/docs/integration-api#get-integration-actions should be the same with the owner team in (https://docs.opsgenie.com/docs/integration-api#get-integration). Integration Update API doesnt update integration_actions Automatically. Integration team will investigate this.

TLDR; Update functionalities were broken in previous version. Fixing these surfaced some lacking functionalities of the Integration API.

Please feel free to add any concerns.

[glenthomas]

@Dekunite thanks for your efforts in getting this fixed promptly. It did appear to us that there were issues with the older versions as there were changes showing on every deployment. I will test 0.6.23 to see if that resolves our problems.

[koushik-swaminathan]

Hi @glenthomas, please let me know if can close this issue.