terraform-provider-pagerduty: Unexpected diffs on pagerduty_extension after 1.2.0 release

The community post linking here is now closed. In lieu of that, I have a question for the people who want to configure this on their own pagerduty instance.

Are you actually interested in maintaining your extension configuration with the pagerduty_extension resource, or just set the extension_objects parameter every time you add a new service?

The latter is my personal use case, I could give a hoot if I had to do a one time configuration of the extension via the pagerduty UI, as long as I can add all of my services to it via the API, because I am programmatically declaring all my Services in the same way and want the same extensions and configuration to apply to all of them.

My suspicion is that most people probably are in the same boat, so if Pagerduty offered an endpoint for just updating the extension_objects field without having to repost the config, that’d solve most people’s problems.

Please emoji here and if there’s enough support for this approach, I guess I’ll open a new support ticket or community topic or something to get that thru.

@pdecat @tdmalone I posted this internally at PagerDuty and will post back what I find out.

Hi @tdmalone, thank you so much for reporting this issue and sorry about this.

I’ve opened a PR (#95) that should address this by allowing the config to be computed if not present in the configuration.

Hi @tdmalone,

I’m not quite sure of the purpose of defining this config in Terraform.

The config field can be used to reuse an existing Slack OAuth token to setup additional service extensions.

Here’s how we do it:

locals {
  extension_config_slack = {
    restrict = "any"

    ok = "true"

    notify_types {
      resolve     = "false"
      acknowledge = "false"
      assignments = "false"
      annotate    = "false"
    }

    scope = "identify,bot,incoming-webhook,channels:read,groups:read,im:read,users:read,users:read.email,chat:write:bot,groups:write"

    user_id   = "${var.pagerduty_slack_extension["user_id"]}"
    team_name = "${var.pagerduty_slack_extension["team_name"]}"
    team_id   = "${var.pagerduty_slack_extension["team_id"]}"

    incoming_webhook = {
      channel           = "${var.pagerduty_slack_extension["incoming_webhook_channel"]}"
      channel_id        = "${var.pagerduty_slack_extension["incoming_webhook_channel_id"]}"
      configuration_url = "${var.pagerduty_slack_extension["incoming_webhook_configuration_url"]}"
      url               = "${var.pagerduty_slack_extension["incoming_webhook_url"]}"
    }

    bot {
      bot_user_id = "${var.pagerduty_slack_extension["bot_user_id"]}"
    }

    access_token = "${var.pagerduty_slack_extension["access_token"]}"
  }

  # FIXME: replace() is needed because jsonencode() encodes booleans as strings until 0.12, cf. https://github.com/hashicorp/terraform/issues/17033

  extension_config_slack_json = "${replace(jsonencode(local.extension_config_slack), "/\"(true|false|[[:digit:]]+)\"/", "$1")}"
}

data "pagerduty_extension_schema" "slack" {
  name = "Slack"
}

resource "pagerduty_extension" "slack_nbh" {
  count = "${length(var.customers_nbh)}"

  name = "${pagerduty_team.team.name} - ${element(var.customers_nbh, count.index)} NBH - ${var.pagerduty_slack_extension["incoming_webhook_channel"]} in ${var.pagerduty_slack_extension["workspace_name"]}"

  endpoint_url = ""

  extension_schema  = "${data.pagerduty_extension_schema.slack.id}"
  extension_objects = ["${element(pagerduty_service.nbh.*.id, count.index)}"]

  config = "${local.extension_config_slack_json}"
}

To retrieve a token from an existing service extension:

# export PAGERDUTY_API_TOKEN=******
# export PAGERDUTY_SERVICE_ID=******
# export PAGERDUTY_EXTENSION_ID=PD8SURB # "Slack" service extension schema
# export SLACK_WORKSPACE=*****.slack.com
# curl -s -X GET --header 'Accept: application/vnd.pagerduty+json;version=2' --header "Authorization: Token token=$PAGERDUTY_API_TOKEN" "https://api.pagerduty.com/extensions?extension_object_id=$PAGERDUTY_SERVICE_ID&extension_schema_id=$PAGERDUTY_EXTENSION_ID&query=${SLACK_WORKSPACE}" | jq '.extensions[0].config.access_token'

@pdecat thx! this works!

@pdecat Hey! Thx for your time. How did you find what bot_access_token_v2 & bot_access_token_v2 values should be?

You should see them in the terraform diff after having set up one Slack extension in the web UI. From there, you can reuse the values for other extensions.

Edit: you can also query the Pagerduty API manually.

Although to surface the other findings per that discussion: changing the bot_access_token will turn the Slack-side behavior to look as if the user for the token you’ve provided is posting all of the messages. It also breaks interactivity – the “Acknowledge”, “Add Note”, etc. buttons no longer work if you set bot_access_token.

Slack interactivity still works for us, and posts are still posted by the Pagerduty bot. Not sure why though.

Sadly, retrieving the access token from the REST API no longer works since yesterday, it is now returned as access_token": "redacted".

I’ve opened a discussion at https://community.pagerduty.com/forum/t/access-token-used-for-service-extension-no-longer-accessible-from-rest-api/1674

@tdmalone I just tested and it looks like extensions newly created via the UI no longer have their access_token field exposed, no matter the extension schemas used.

It does not bother me so far because I’m always reusing the same token for all extensions, in the same slack workspace.

I would be in trouble if I needed to integrate with other slack workspaces.

Maybe someone should reach to Pagerduty support to get to the bottom of it.

Maybe there could be an API endpoint to reference OAuth access tokens by some criteria without exposing the underlying secrets.

Is this still an issue in provider.pagerduty v1.2.1?

Yep, looks like #95 hasn’t been merged yet.

@pdecat Ooh that is nice indeed. Thank you for the use case! I like the idea of using jsonencode too. I’ve been using HEREDOC syntax elsewhere to make JSON more readable 😃

@acrewdson I think that is likely related to the same issue.

To be honest, I’m not quite sure of the purpose of defining this config in Terraform. There’s probably cases I’m not aware of, but for us, when using with Slack, we generally have to set up the authorization through the PagerDuty UI anyway, as the config ends up containing the ‘link’ to the Slack team. There’s not a lot of point that I can see in us managing this through Terraform.

We’ve still got our pagerduty provider pinned to 1.1.0 due to this issue, but when #95 is merged I suspect we’ll be able to update and just not supply ‘config’, thereby maintaining the old behaviour.