feat: add pagerduty_event_orchestrations datasource

[fgouteroux]

Hello,

I want to add a new datasource pagerduty_event_orchestrations which allow to search multiples event_orchestration with a regex.

Example:

data "pagerduty_event_orchestrations" "example" {
  search = ".*Orchestration$"
}

I added:

• doc
• tests

[fgouteroux]

any updates ?

[gsreynolds]

Rebased to resolve conflicts; @imjaroiswebdev can you please review when able? Much appreciated

[gsreynolds]

Hi @fgouteroux - just for context, it would help if you could elaborate on the use case here.

From your example in the doc:

resource "pagerduty_event_orchestration" "tf_orch_a" {
  name = "Test Event A Orchestration"
}
resource "pagerduty_event_orchestration" "tf_orch_b" {
  name = "Test Event B Orchestration"
}
data "pagerduty_event_orchestrations" "tf_my_monitor" {
  search = ".*Orchestration$"
}

I'm presuming in your scenario that you might not know ahead of time that EOs (A & B) exist that might match ".*Orchestration$", however... what are you then looking to do with the returned data? Thanks

[fgouteroux]

Hi @fgouteroux - just for context, it would help if you could elaborate on the use case here.

From your example in the doc:

resource "pagerduty_event_orchestration" "tf_orch_a" {
  name = "Test Event A Orchestration"
}
resource "pagerduty_event_orchestration" "tf_orch_b" {
  name = "Test Event B Orchestration"
}
data "pagerduty_event_orchestrations" "tf_my_monitor" {
  search = ".*Orchestration$"
}

I'm presuming in your scenario that you might not know ahead of time that EOs (A & B) exist that might match ".*Orchestration$", however... what are you then looking to do with the returned data? Thanks

Hello @gsreynolds , We need to get the integration keys in order to configure our alertmanager. We have a naming convention for the event orchestration (the owner team name in the name of EO).

Today we have declare n datasources to get the event orchestration matching the exact name. Each datasource made a Pagerduty http call and it is useless to perform n call when we can do it once.

At the end we need want to configure multiple alertmanager pagerduty_receivers, one for each integration_key.

data "pagerduty_event_orchestration" "messaging" {
  name = "myteam.messaging"
}

data "pagerduty_event_orchestration" "monitoring" {
  name = "myteam.monitoring"
}

module "mimir_alertmanager_config" {
  source             = "git::ssh://git@gitlab.example.com/terraform/modules/prometheus_alertmanager_config.git"
  default_route = {
    receiver = "pagerduty_default"
  }
  routes = [
    {
      receiver = "pagerduty_messaging"
      matchers = ["ecosystem=\"stack_messaging\""]
    },
    {
      receiver = "pagerduty_monitoring"
      matchers = ["ecosystem=\"stack_monitoring\""]
    }
  ]
  receivers_pagerduty = [
 
    {
      name        = "pagerduty_messaging"
      routing_key = "${data.pagerduty_event_orchestration.messaging.routing_keys[0]}"
    },
    {
      name        = "pagerduty_monitoring"
      routing_key = "${data.pagerduty_event_orchestration.monitoring.routing_keys[0]}"
    }
  ]
}

With the datasource

data "pagerduty_event_orchestrations" "myteam" {
  search = "^myteam.*"
}

I can retrieve all integration keys for myteam and then build a data map like this:

tomap({
     for k, rs in data.pagerduty_event_orchestrations.myteam.event_orchestrations : rs.name => rs.integration[0].parameters[0].routing_key
 })

so I can automatically configure a pagerduty receiver for each integration key found.

[imjaroiswebdev]

Hi @fgouteroux I really appreciate your contribution and I'm also able to understand the value in this new data source you are introducing, however, I would ask you to first address a few comments I left as my review to proceed with its approval and merge. Thanks again! ✌🏽

Please don't hesitate in asking for help or if you need me to elaborate more on my comments. I'm also open to push the patches to cover my comments in order to accelerate the merge of this PR. You only have to let me know 💪🏽

[gsreynolds]

@fgouteroux Thanks for your use case and I understand better now

In my personal opinion, it seems not to be entirely in keeping with the declarative nature of Terraform. Still, I appreciate the scenario and acknowledge that “list” style resources exist elsewhere.

As @imjaroiswebdev has suggested, we would prefer to rename the attribute search to name_filter. If you look at similar “list” style data sources elsewhere they have a filter block for key/value pairs, but we only have a name (maybe team) here… For example:

registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/availability_zones
registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/instances

[imjaroiswebdev]

All comments have been addressed ✌🏽

[gsreynolds]

LGTM 🚀

[imjaroiswebdev]

Awesome! Thank you @fgouteroux for adding this new data source and also @gsreynolds for all your help during the review, I really like the use case for this data source 💪🏽 🎉

[gsreynolds]

Thank you @fgouteroux and @imjaroiswebdev! 🥳

[fgouteroux]

Thank you so much for the review @gsreynolds and for your additional work @imjaroiswebdev !

[imjaroiswebdev]

Hey @fgouteroux and @gsreynolds this new Data Source you introduced in now available on PagerDuty Terraform Provider v2.10.0 Thank you! 🎉 💪🏽 🚀