[datadog_integration_pagerduty_service_object] Add data source for pagerduty service objects

[nkzou]

Supersedes #1771, Original PR by @scemily13

Adds the pagerduty_integration_service_object datasource to query for its existence so as to determine whether or not to create the same integration again.

Original issue: #1718

[hestonhoffman]

Small nit

[scemily13]

Hi @hestonhoffman @nkzou -- any updates on this?

[hestonhoffman]

LGTM!

[nkzou]

Hi there, we've looked into the PR and we don't think the data source works as expected. The goal was to query the existence of the service object to avoid recreating it in a different terraform project/state, right? The given example code doesn't accomplish that, because the logic length(data.datadog_integration_pagerduty_service_object.foo) > 0 ? 1 : 0 will still try to recreate the object if run in a different terraform state.

Moving forward we plan on changing the data source to one that returns a list of all pagerduty service objects, though I don't expect this to fit your use case either, since I believe this pattern goes against terraform's design. See hashicorp/terraform#23178 (comment). Could you share a bit more about your environment and use case? Multiple terraform states should not be attempting to manage a single object.

Hopefully that all made sense and explains why we're not moving forward with the PR as it is now, let me know if I've misunderstood anything.

[skang0601]

Moving forward we plan on changing the data source to one that returns a list of all pagerduty service objects, though I don't expect this to fit your use case either, since I believe this pattern goes against terraform's design.

That would still work for our use case but that looks like it would require a change in the API since it only allows for looking up a single integration.

Could you share a bit more about your environment and use case? Multiple terraform states should not be attempting to manage a single object.

We're distributing out a Terraform module for managing a PD service object in Pagerduty and then setting up the integration in Datadog. This standardizes the naming of these resources and allows us to also deterministically output the routing string (@pagerduty-*) for usage in their monitors.

Our general setup is that each team/application maintains their own Terraform repository/state for their monitoring setup. But certain teams may want to define monitors in their codebase but route the alert to another's team Pagerduty service, so currently, they'll use the same module for creating the Pagerduty service/integration but pass a flag to the module to disable the creation of the service/integration to just get the routing string.

This setup has caused confusion for people since it requires the users to know if a pagerduty integration already exists and pass in the flag to disable creation.