pagerduty/terraform-provider-pagerduty

Terraform PagerDuty provider

Terraform Provider for PagerDuty

• Website: https://registry.terraform.io/providers/PagerDuty/pagerduty/latest
• Documentation: https://registry.terraform.io/providers/PagerDuty/pagerduty/latest/docs
• Terraform Gitter:
• Mailing list: Terraform Google Groups

PagerDuty is an alarm aggregation and dispatching service for system administrators and support teams. It collects alerts from your monitoring tools, gives you an overall view of all of your monitoring alarms, and alerts an on duty engineer if there’s a problem. The Terraform Pagerduty provider is a plugin for Terraform that allows for the management of PagerDuty resources using HCL (HashiCorp Configuration Language).

Requirements

• Terraform 0.12.x
• Go 1.20 (to build the provider plugin)

Building the Provider

Clone repository to: $GOPATH/src/github.com/PagerDuty/terraform-provider-pagerduty

$ mkdir -p $GOPATH/src/github.com/PagerDuty; cd $GOPATH/src/github.com/PagerDuty
$ git clone [email protected]:PagerDuty/terraform-provider-pagerduty

Enter the provider directory and build the provider

$ cd $GOPATH/src/github.com/PagerDuty/terraform-provider-pagerduty
$ make build
...
$ $GOPATH/bin/terraform-provider-pagerduty
...

This will build the provider and put the provider binary in the $GOPATH/bin directory.

Usage

Please refer to Terraform docs for PagerDuty Provider for examples on how to use the provider and detailed documentation about the Resources and Data Sources the provider has.

Caching Support

The go-pagerduty library relies on various APIs to interact with PagerDuty's resources. However, some of these APIs lack efficient ways to query specific resources by their attributes. When an implementation in the Terraform Provider requires such logic, the library lists all resources of a specific entity and performs a lookup in memory. This can result in inefficient use of the APIs, especially when dealing with a large number of resources, as the repetitive API calls for listing resource definitions can lead to significant time consumption and performance penalties. To address this issue, we have introduced caching to improve the user experience when interacting with Terraform resources that rely on API calls to list all available data for a specific entity, and then perform a lookup by attribute value in memory. With this improvement, the Terraform Provider users can expect better performance and faster response times when working with PagerDuty's resources.

Resources currently supporting cache of API calls

• pagerduty_team_membership
• pagerduty_user_contact_method
• pagerduty_user_notification_rule
• pagerduty_user

Caching mechanisms available

• In memory.
• MongoDB.

To activate caching support

Environment Variable	Example Value	Description
TF_PAGERDUTY_CACHE	memory	Activate In Memory cache.
TF_PAGERDUTY_CACHE	mongodb+srv://[mongouser]:[mongopass]@[mongodbname].[mongosubdomain].mongodb.net	Activate MongoDB cache.
TF_PAGERDUTY_CACHE_MAX_AGE	30s	Only applicable for MongoDB cache. Time in seconds for cached data to become staled. Default value 10s.
TF_PAGERDUTY_CACHE_PREFILL	1	Only applicable for MongoDB cache. Indicates to pre-fill data in cache for Abilities, Users, Contact Methods and Notification Rules.

Development

Setup Local Environment

Before developing the provider, ensure that you have go correctly installed.

• Install Go on your machine (version 1.11+ is required).
• Correctly setup a GOPATH, as well as adding $GOPATH/bin to your $PATH.

Setup Local PagerDuty Provider

Make changes to the PagerDuty provider and post a pull request for review.

1. Create a fork of the upstream repository https://github.com/PagerDuty/terraform-provider-pagerduty
2. Clone the new origin repository to your local go src path: $GOPATH/src/github.com/<your-github-username>/terraform-provider-pagerduty
3. optionally make development easier by setting the upstream repository

   $ git remote add upstream [email protected]:PagerDuty/terraform-provider-pagerduty.git
   

4. Make any changes on your local machine and post a PR to the upstream repository

Run Dev Build with Local Terraform Module

Note: Development overrides work only in Terraform v0.14 and later. Using a dev_overrides block in your CLI configuration will cause Terraform v0.13 to reject the configuration as invalid.

1. Build the provider with your latest changes. (See Building the Provider)
2. Override the pagerduty provider with your local build. (See Development Overrides for Provider Developers)
   • Create the file $HOME/.terraformrc and paste the following content into it. Be sure to change the path to wherever your binary is located. It is currently set to the default for go builds.

   provider_installation {
      dev_overrides {
         "pagerduty/pagerduty" = "/<ABSOLUTE_PATH_TO>/<YOUR_HOME_PATH>/go/bin"
      }
      direct {}
   }

3. Goto a local terraform module and start running terraform. (See Using the Provider). You may need to first install the latest module and provider versions allowed within the new configured constraints. Verify with the below warning message.

   $ terraform init -upgrade
   $ terraform plan
   ...
   │ Warning: Provider development overrides are in effect

4. See api_url_override from Terraform docs for PagerDuty Provider to set a custom proxy endpoint as PagerDuty client api url overriding service_region setup.

Test a specific version of the go-pagerduty API client

Modify the go.mod file using a Go module replacement for `github.com/heimweh/go-pagerduty:

$ go mod edit -replace github.com/heimweh/go-pagerduty=/PATH/TO/LOCAL/github.com/<USERNAME>/<REPO>

Or update the file directly:

replace github.com/heimweh/go-pagerduty => /PATH/TO/LOCAL/go-pagerduty

Update vendored dependencies or configure compiler to prefer using downloaded modules based on go.mod file:

$ export GOFLAGS="-mod=mod"

Or:

$ go mod vendor

Setup Local Logs

1. See Debugging Terraform. Either add this to your shell's profile (example: ~/.bashrc), or just execute these commands:

   export TF_LOG=trace
   export TF_LOG_PATH="/PATH/TO/YOUR/LOG_FILE.log"
   

2. stream logs

   $ tail -f /PATH/TO/YOUR/LOG_FILE.log
   

Secure Logs Level

In addition to the log levels provided by Terraform, namely TRACE, DEBUG, INFO, WARN, and ERROR (in descending order of verbosity), the PagerDuty Provider introduces an extra level called SECURE. This level offers verbosity similar to Terraform's debug logging level, specifically for the output of API calls and HTTP request/response logs. The key difference is that API keys within the request's Authorization header will be obfuscated, revealing only the last four characters. An example is provided below:

---[ REQUEST ]---------------------------------------
GET /teams/DER8RFS HTTP/1.1
Accept: application/vnd.pagerduty+json;version=2
Authorization: <OBSCURED>kCjQ
Content-Type: application/json
User-Agent: (darwin arm64) Terraform/1.5.1

To enable the SECURE log level, you must set two environment variables:

• TF_LOG=INFO
• TF_LOG_PROVIDER_PAGERDUTY=SECURE

Testing

In order to test the provider, you can simply run make test.

$ make test

In order to run the full suite of Acceptance tests, run make testacc. Running the acceptance tests requires that the PAGERDUTY_TOKEN environment variable be set to a valid API Token and that the PAGERDUTY_USER_TOKEN environment variable be set to a valid API User Token. Many tests also require that the Email Domain Restriction feature either be disabled or be configured to include foo.test as an allowed domain.

Note: Acceptance tests create real resources, and often cost money to run.

$ make testacc

Additional Note: In order for the tests on the Slack Connection resources to pass you will need valid Slack workspace and channel IDs from a Slack workspace connected to your PagerDuty account.

Run a specific subset of tests by name use the TESTARGS="-run TestName" option which will run all test functions with "TestName" in their name.

$ make testacc TESTARGS="-run TestAccPagerDutyTeam"

Some tests require additional environment variables to be set to enable them due to account restrictions on certain features. Similarly to TF_ACC, the value of the environment variable is not relevant.

For example:

PAGERDUTY_ACC_INCIDENT_WORKFLOWS=1 make testacc TESTARGS="-run PagerDutyIncidentWorkflow"
PAGERDUTY_ACC_SERVICE_INTEGRATION_GENERIC_EMAIL_NO_FILTERS="user@<your_domain>.pagerduty.com" make testacc TESTARGS="-run PagerDutyServiceIntegration_GenericEmailNoFilters"
PAGERDUTY_ACC_INCIDENT_CUSTOM_FIELDS=1 make testacc TESTARGS="-run PagerDutyIncidentCustomField"
PAGERDUTY_ACC_LICENSE_NAME="Full User" make testacc TESTARGS="-run DataSourcePagerDutyLicense_Basic"
PAGERDUTY_ACC_SCHEDULE_USED_BY_EP_W_1_LAYER=1 make testacc TESTARGS="-run PagerDutyScheduleWithTeams_EscalationPolicyDependantWithOneLayer"

Variable Name	Feature Set
PAGERDUTY_ACC_INCIDENT_WORKFLOWS	Incident Workflows
PAGERDUTY_ACC_SERVICE_INTEGRATION_GENERIC_EMAIL_NO_FILTERS	Service Integration
PAGERDUTY_ACC_INCIDENT_CUSTOM_FIELDS	Custom Fields
PAGERDUTY_ACC_LICENSE_NAME	Licenses
PAGERDUTY_ACC_SCHEDULE_USED_BY_EP_W_1_LAYER	Schedule
PAGERDUTY_ACC_EXTERNAL_PROVIDER_VERSION	Modifies the version used to compare plans between sdkv2 and framework implementations. Default ~> 3.6.

terraform-provider-pagerduty's Issues

Removal of user with dependencies fails

Terraform Version

v0.11.3

Affected Resource(s)

Please list the resources as a list, for example:

• pagerduty_user
• pagerduty_schedule
• pagerduty_escalation_policy

Terraform Configuration Files

This one is a little hard due to the structure. In simple form, we had:

• an array of pagerduty_users
• a pagerduty_schedule that the users were members of
• two pagerduty_escalation_policies that referenced the pagerduty_schedule

Debug Output

Plan:

------------------------------------------------------------------------
  |  
  | An execution plan has been generated and is shown below.
  | Resource actions are indicated with the following symbols:
  | ~ update in-place
  | - destroy
  |  
  | Terraform will perform the following actions:
  |  
  | ~ pagerduty_escalation_policy.blah0
  | rule.1.target.#:                    "4" => "3"
  | rule.1.target.3.id:                 "XXXXXX0" => ""
  |  
  | ~ pagerduty_escalation_policy.blah1
  | rule.#:                             "2" => "1"
  | rule.1.escalation_delay_in_minutes: "30" => "0"
  | rule.1.target.#:                    "1" => "0"
  | rule.1.target.0.id:                 "XXXXXX1" => ""
  |  
  | ~ pagerduty_escalation_policy.blah2
  | rule.1.target.#:                    "4" => "3"
  | rule.1.target.3.id:                 "XXXXXX0" => ""
  |  
  | ~ pagerduty_escalation_policy.blah3
  | rule.#:                             "2" => "1"
  | rule.1.escalation_delay_in_minutes: "30" => "0"
  | rule.1.target.#:                    "1" => "0"
  | rule.1.target.0.id:                 "XXXXXX1" => ""
  |  
  | ~ module.pagerduty.pagerduty_schedule.on_call_shift
  | layer.0.users.#:                    "4" => "3"
  | layer.0.users.2:                    "XXXXXX0" => "XXXXXX2"
  | layer.0.users.3:                    "XXXXXX2" => ""
  |  
  | - module.pagerduty.pagerduty_user.devops[3]

Expected Behavior

• User is able to be destroyed when the relevant dependencies are deleted as part of the terraform plan to be applied.

Actual Behavior

• User failed to be deleted as dependencies were not destroyed first (and were part of the plan).

module.pagerduty.pagerduty_user.devops[3]: Destroying... (ID: XXXXXX0)
  |  
  | Error: Error applying plan:
  |  
  | 1 error(s) occurred:
  |  
  | * module.pagerduty.pagerduty_user.devops[3] (destroy): 1 error(s) occurred:
  |  
  | * pagerduty_user.devops.3: DELETE API call to https://api.pagerduty.com/users/XXXXXX0 failed 400 Bad Request. Code: 0, Errors: [The user cannot be deleted as they have 2 escalation policies and 1 schedule. Please remove the user from the following escalation policies and remove the user from the following schedule to continue.], Message:

Unable to locate extension schema

Terraform Version

Terraform v0.10.7
Pagerduty Provider v1.0.0

Affected Resource(s)

• pagerduty_extension_schema

Terraform Configuration Files

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

Debug Output

Please provider a link to a GitHub Gist containing the complete debug output: https://www.terraform.io/docs/internals/debugging.html. Please do NOT paste the debug output in the issue; just paste a link to the Gist.

Expected Behavior

Terraform should have created a pagerduty_extension resource using the schema

Actual Behavior

Terraform output an error

Error refreshing state: 1 error(s) occurred:

* data.pagerduty_extension_schema.slack: 1 error(s) occurred:

* data.pagerduty_extension_schema.slack: data.pagerduty_extension_schema.slack: Unable to locate any extension schema with the name: Slack

Steps to Reproduce

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

1. Create pagerduty_extension_schema object like

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

2. Create a pagerduty_extension resource which references the pagerduty_extension_schema
3. terraform plan

Important Factoids

This was working a few days ago. Haven't made any changes to our codebase

References

Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

• GH-1234

User cannot be added to a team

Terraform Version

Terraform v0.11.13

• provider.pagerduty v1.2.1

Affected Resource(s)

Please list the resources as a list, for example:

• pagerduty_user

Terraform Configuration Files

provider "pagerduty" {
  token = "MY-TOKEN"
  alias = "ei"
}

resource "pagerduty_user" "limitusus" {
  provider    = "pagerduty.ei"
  name        = "Tomoya Kabe"
  email       = "[email protected]"
  color       = "green"
  role        = "owner"
  job_title   = "Site Reliability Engineer"
  teams       = ["${pagerduty_team.ei.id}"]
  description = ""
}

resource "pagerduty_team" "ei" {
  provider    = "pagerduty.ei"
  name        = "ElasticInfra"
  description = "All ElasticInfra SREs"
}

Debug Output

2019/03/18 11:35:44 [DEBUG] apply: pagerduty_user.limitusus: executing Apply
2019-03-18T11:35:44.968+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: 2019/03/18 11:35:44 [INFO] Updating PagerDuty user PELBHBE
2019-03-18T11:35:44.968+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: 2019/03/18 11:35:44 [DEBUG] PagerDuty - Preparing PUT request to /users/PELBHBE with body: {"user":{"color":"green","em
ail":"[email protected]","job_title":"Site Reliability Engineer","name":"Tomoya Kabe","time_zone":"Asia/Tokyo"}}
2019-03-18T11:35:44.968+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: 2019/03/18 11:35:44 [WARN] Invalid log level: "1". Defaulting to level: TRACE. Valid levels are: [TRACE DEBUG INFO WARN
 ERROR]
2019-03-18T11:35:44.968+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: 2019/03/18 11:35:44 [DEBUG] PagerDuty API Request Details:
2019-03-18T11:35:44.968+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: ---[ REQUEST ]---------------------------------------
2019-03-18T11:35:44.968+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: PUT /users/PELBHBE HTTP/1.1
2019-03-18T11:35:44.968+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: Host: api.pagerduty.com
2019-03-18T11:35:44.968+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: User-Agent: (linux amd64) Terraform/0.10.0-dev
2019-03-18T11:35:44.968+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: Content-Length: 146
2019-03-18T11:35:44.968+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: Accept: application/vnd.pagerduty+json;version=2
2019-03-18T11:35:44.968+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: Authorization: Token token=zJopsV-hYXfbixKvAuA6
2019-03-18T11:35:44.968+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: Content-Type: application/json
2019-03-18T11:35:44.968+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: Accept-Encoding: gzip
2019-03-18T11:35:44.968+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: 
2019-03-18T11:35:44.968+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: 
2019-03-18T11:35:44.968+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: -----------------------------------------------------
2019-03-18T11:35:45.177+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: 2019/03/18 11:35:45 [WARN] Invalid log level: "1". Defaulting to level: TRACE. Valid levels are: [TRACE DEBUG INFO WARN
 ERROR]
2019-03-18T11:35:45.177+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: 2019/03/18 11:35:45 [DEBUG] PagerDuty API Response Details:
2019-03-18T11:35:45.177+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: ---[ RESPONSE ]--------------------------------------
2019-03-18T11:35:45.177+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: HTTP/2.0 403 Forbidden
2019-03-18T11:35:45.177+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: Access-Control-Allow-Headers: Authorization, Content-Type, AuthorizationOauth, From
2019-03-18T11:35:45.177+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
2019-03-18T11:35:45.177+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: Access-Control-Allow-Origin: *
2019-03-18T11:35:45.177+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: Access-Control-Max-Age: 1728000
2019-03-18T11:35:45.177+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: Cache-Control: no-cache
2019-03-18T11:35:45.177+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: Content-Type: application/json
2019-03-18T11:35:45.177+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: Date: Mon, 18 Mar 2019 02:35:45 GMT
2019-03-18T11:35:45.177+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: Server: nginx
2019-03-18T11:35:45.177+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: Status: 403 Forbidden
2019-03-18T11:35:45.177+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: X-Request-Id: 97a658ee-439b-4e77-ad40-0108bf994446
2019-03-18T11:35:45.177+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: X-Ua-Compatible: IE=Edge,chrome=1
2019-03-18T11:35:45.177+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: 
2019-03-18T11:35:45.177+0900 [DEBUG] plugin.terraform-provider-pagerduty_v1.2.1_x4: -----------------------------------------------------
2019/03/18 11:35:45 [TRACE] root: eval: *terraform.EvalWriteState
2019/03/18 11:35:45 [TRACE] root: eval: *terraform.EvalApplyProvisioners
2019/03/18 11:35:45 [TRACE] root: eval: *terraform.EvalIf
2019/03/18 11:35:45 [TRACE] root: eval: *terraform.EvalWriteState
2019/03/18 11:35:45 [TRACE] root: eval: *terraform.EvalWriteDiff
2019/03/18 11:35:45 [TRACE] root: eval: *terraform.EvalApplyPost
2019/03/18 11:35:45 [ERROR] root: eval: *terraform.EvalApplyPost, err: 1 error(s) occurred:

* pagerduty_user.limitusus: PUT API call to https://api.pagerduty.com/users/PELBHBE failed 403 Forbidden. Code: 2010, Errors: <nil>, Message: Access Denied

Panic Output

No Panic

Expected Behavior

The user is added to the team

Actual Behavior

As seen the above log, I receive an error of "Access Denied"

• pagerduty_user.limitusus: PUT API call to https://api.pagerduty.com/users/PELBHBE failed 403 Forbidden. Code: 2010, Errors: , Message: Access Denied

Steps to Reproduce

1. terraform apply

Important Factoids

The PD account is brand-new trial one.
Also as seen the HCL I'm using a provider alias for this account.

References

N/A

Validate days of week

I mistakenly assumed the days of the week were 0 indexed. Some validation around this would be nice.

Terraform Version

All versions

Affected Resource(s)

Please list the resources as a list, for example:

• pagerduty_service

Terraform Configuration Files

resource "pagerduty_service" "foo" {
	name                    = "foo"
	description             = "bar bar bar"
	auto_resolve_timeout    = 3600
	acknowledgement_timeout = 3600
	escalation_policy       = "${pagerduty_escalation_policy.foo.id}"
	}
	support_hours = [{
		type         = "fixed_time_per_day"
		time_zone    = "America/Lima"
		start_time   = "09:00:00"
		end_time     = "17:00:00"
		days_of_week = [0, 1, 2, 3, 4, 5 ]
	}]
}

Expected Behavior

What should have happened?
terraform plan should have failed with a validation error

Actual Behavior

What actually happened?
It succeeded but made the state wonky and showed changes for the field on all subsequent plans.

Steps to Reproduce

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

1. terraform apply

Add email_filters to pagerduty_service_integration of type generic_email_inbound_integration

Hi there,

I am using the generic_email_inbound_integration type of pagerduty_service_integration.
Being as it is, I heavily depend on some email filtering.

The pagerduty API itself seems to be a bit underdocumented (can't find a schema for this) but below is roughly the response of my manually created service integration.

https://api.pagerduty.com/services/__service__/integrations/__integration__

{
  "integration": {
    "type": "generic_email_inbound_integration",
    // snip
    "email_incident_creation": "on_new_email_subject",
    "email_filter_mode": "and-rules-email",
    "email_filters": [
      {
        "subject_mode": "no-match",
        "subject_regex": "__insert regex here__",
        "body_mode": "always",
        "body_regex": null,
        "from_email_mode": "always",
        "from_email_regex": null,
        "id": "__id__"
      }
    ],
    "email_parsers": null,
    "email_parsing_fallback": null
  }
}

Would you be interested in adding email_filters into your PagerDuty provider?

Cheers, Mathias

Migrate Codebase from govendor to Go Modules

Description

Go 1.11 has introduced Go modules, which looks like the official solution for dependency management going forward.

References

hashicorp/terraform-provider-aws#5773
https://github.com/golang/go/wiki/Modules

Updating configuration of a service where the status is currently 'critical' or 'warning' fails

It seems the Pagerduty API fails with a 400 when attempting to update the attributes of a service with an active incident on it resulting in its status being either warning or critical. This might just be a bug in the PagerDuty API though.

Terraform Version

Terraform v0.11.6

Affected Resource(s)

• resource "pagerduty_service"

Terraform Configuration Files

resource "pagerduty_service" "service" {
  name                    = "test"
  description             = "description"
  acknowledgement_timeout = "null"
  auto_resolve_timeout    = "null"
  escalation_policy       = "<ID>"
  alert_creation          = "create_alerts_and_incidents"

  incident_urgency_rule {
    type    = "constant"
    urgency = "high"
  }
}

Expected Behavior

Successful update of the configuration of the service

Actual Behavior

* module.business-systems.pagerduty_service.service: 1 error(s) occurred:

* pagerduty_service.service: PUT API call to https://api.pagerduty.com/services/PKS1O3C failed 400 Bad Request. Code: 2001, Errors: [Status must be in active or disabled.], Message: Invalid Input Provided

Steps to Reproduce

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

1. terraform apply - create service
2. change a single attribute, like the description of the service
3. re-apply while that service is in a state where it has an active incident on it.

Team datasource doesn't recognise specifically formatted team names.

Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

Terraform v0.11.10

• provider.pagerduty v1.2.1

Affected Resource(s)

Please list the resources as a list, for example:

• pagerduty_team - data source

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

variable "team_name" {
  type    = "string"
  default = "TF Test Team"
}
provider "pagerduty" {
  token = "${var.pagerduty_token}"
}
resource "pagerduty_team" "example" {
  name        = "${var.team_name}"
  description = "All engineering"
}
data "pagerduty_team" "example" {
  name = "${var.team_name}"
}

Debug Output

https://gist.github.com/brettmillerb/5ee1657bed29c2000a2fba6e3525769d

Panic Output

N/A

Expected Behavior

Successfully loaded team using data source

Actual Behavior

terraform plan failed due to inability to find team which exists. Other team names working fine. Also tested with ZZ Test Team which failed so appears to be an issue with the request or filtering of the request for specific team names.

Steps to Reproduce

• Manually Create team called TF Test Team or ZZ Test Team
• Attempt to load that team in as a data source

Important Factoids

N/A

References

N/A

Extend service integration

Hi there,

Right not there is possibility to set:

The service type. Can be: aws_cloudwatch_inbound_integration, cloudkick_inbound_integration, event_transformer_api_inbound_integration, generic_email_inbound_integration, generic_events_api_inbound_integration, keynote_inbound_integration, nagios_inbound_integration, pingdom_inbound_integrationor sql_monitor_inbound_integration.

Could you extend it and add NewRelic, Bosun and StackDriver?

[PROPOSAL] Switch to Go Modules

As part of the preparation for Terraform v0.12, we would like to migrate all providers to use Go Modules. We plan to continue checking dependencies into vendor/ to remain compatible with existing tooling/CI for a period of time, however go modules will be used for management. Go Modules is the official solution for the go programming language, we understand some providers might not want this change yet, however we encourage providers to begin looking towards the switch as this is how we will be managing all Go projects in the future. Would maintainers please react with 👍 for support, or 👎 if you wish to have this provider omitted from the first wave of pull requests. If your provider is in support, we would ask that you avoid merging any pull requests that mutate the dependencies while the Go Modules PR is open (in fact a total codefreeze would be even more helpful), otherwise we will need to close that PR and re-run go mod init. Once merged, dependencies can be added or updated as follows:

$ GO111MODULE=on go get github.com/some/module@master
$ GO111MODULE=on go mod tidy
$ GO111MODULE=on go mod vendor

GO111MODULE=on might be unnecessary depending on your environment, this example will fetch a module @ master and record it in your project's go.mod and go.sum files. It's a good idea to tidy up afterward and then copy the dependencies into vendor/. To remove dependencies from your project, simply remove all usage from your codebase and run:

$ GO111MODULE=on go mody tidy
$ GO111MODULE=on go mod vendor

Thank you sincerely for all your time, contributions, and cooperation!

Feature Request: recurring maintenance windows for services

PagerDuty has the ability to schedule recurring maintenance windows through their API, although this is not yet available through the UI. This would be invaluable for setting up scheduled maintenance (e.g. service restarts, server reboots) without going through a separate process after deploying infrastructure to create the recurring maintenance windows via API call.

Reference

Terraform Version

0.11.11

Affected Resource(s)

pagerduty_maintenance_window

API returns a default incident_urgency_rule so always changes

Hi there,

Terraform Version

Using plugin version 0.1.3

Affected Resource(s)

• pagerduty_service

Terraform Configuration Files

resource "pagerduty_service" "service" {
  name                    =  "${var.service_name}"
  description             = "Development ${var.service_name} service"
  auto_resolve_timeout    = 14400
  acknowledgement_timeout = 600
  escalation_policy       = "${data.pagerduty_escalation_policy.team_policy.id}"
  alert_creation          = "create_alerts_and_incidents"
}

Expected Behavior

Running twice should not result in any changes

Actual Behavior

  ~ module.my_module.module.authentication.pagerduty_service.service
      incident_urgency_rule.#:         "1" => "0"
      incident_urgency_rule.0.type:    "constant" => ""
      incident_urgency_rule.0.urgency: "high" => ""

Other

It appears that after you first create the service pagerduty will apply a default incident_urgency_rule of type: constant, urgency: high. When you later fetch that rule from pagerduty it is in the service and so pagerduty will always produce a change that tries to remove the default incident_urgency_rule. It has no effect, but it means that my terraform never cleanly applies.

Service using supported hours and severity based escalation - problem with scheduled actions

Hello,

We are using the terraform provider to setup our PagerDuty configuration. We are having a problem with one aspect of it.

• Terraform version: 0.11.8 (via Docker container)
• Resource: pagerduty_service

The service setup we are trying to setup is as follows:

• Use support hours setup
• During support hours, all incidents escalate by default (urgency = "high")
• After hours, incidents escalate based on severity (urgency = "severity_based")

Through the UI, this is possible - this results in the following service definition (specific section cut for brevity - can provide full if needed):

    "incident_urgency_rule": {
        "type": "use_support_hours",
        "during_support_hours": {
          "type": "constant",
          "urgency": "high"
        },
        "outside_support_hours": {
          "type": "constant",
          "urgency": "severity_based"
        }
      },
      "scheduled_actions": [],
      "support_hours": {
        "type": "fixed_time_per_day",
        "time_zone": "Canada/Toronto",
        "days_of_week": [
          1,
          2,
          3,
          4,
          5
        ],
        "start_time": "09:00:00",
        "end_time": "17:00:00"
      },

Using the pagerduty provider, I can't replicate this as any attempt to use the "use_support_hours" type REQUIRES the schedule_actions block, and that block cannot be empty/null or assigned to an empty list.

Basically, the current logic in PagerDuty seems to be that whenever we use severity based alerting for a support hours based service, we need to provide an empty list to the scheduled actions:

During Support Hours	Outside Support Hours	Scheduled Actions Required
High	Low	Required
Low	High	Required
Severity based	High/Low	Empty List
High/Low	Severity based	Empty List

This may be possible in the current codebase - have tried several permutations of providing the scheduled_actions section with both an empty list or full of null / empty values but unable to accomplish this successfully as of yet. Attempts:

resource "pagerduty_service" "escalate_after_hours_service" {
  name                    = "${var.service_name}"
  escalation_policy       = "${var.escalation_policy_id}"
  description             = "${var.service_description} - Managed by Terraform"
  auto_resolve_timeout    = "null"
  acknowledgement_timeout = "null"
  alert_creation          = "create_alerts_and_incidents"

  incident_urgency_rule {
    type    = "use_support_hours"
    
    during_support_hours {
      type    = "constant"
      urgency = "high"
    }

    outside_support_hours {
      type    = "constant"
      urgency = "severity_based"
    }
  }

  support_hours {
    type         = "fixed_time_per_day"
    time_zone    = "Canada/Toronto"
    start_time   = "${var.support_hours_start_time}"
    end_time     = "${var.support_hours_end_time}"
    days_of_week = "${var.days_of_week}"
  }

#  scheduled_actions = [] - API Failure - Errors: [Scheduled actions is required.]
#  scheduled_actions { } - panic: interface conversion: interface {} is nil, not map[string]interface {}
}

Any and all help much appreciated, Thanks.

Add support for push_notification_contact_method type in pagerduty_user_contact_method resource

Versions

Terraform: v0.11.7
Pagerduty: v1.1.0

Affected Resource(s)

• pagerduty_user_contact_method

Terraform Configuration Files

provider "pagerduty" {}

resource "pagerduty_user" "example" {
  color       = "green"
  description = ""
  email       = "[email protected]"
  job_title   = "Example"
  name        = "example"
  role        = "user"
}

resource "pagerduty_user_contact_method" "example" {
  address = "<LONG_NOTIFICATION_ID>"
  label   = "Label"
  type    = "push_notification_contact_method"
  user_id = "${pagerduty_user.example.id}"
}

Expected Behavior

terraform plan and terraform apply complete successfully.

Actual Behavior

terraform plan and terraform apply fail with errors like this:

Error: pagerduty_user_contact_method.example: "push_notification_contact_method" is an invalid value for argument type. Must be one of []string{"email_contact_method", "phone_contact_method", "sms_contact_method"}

Steps to Reproduce

1. Copy example configuration provided above;
2. Run terraform plan or terraform apply and see error mentioned in Actual Behavior section.

Unexpected diffs on pagerduty_extension after 1.2.0 release

Terraform Version

Terraform v0.11.7
+ provider.aws v1.32.0
+ provider.dns v2.0.0
+ provider.null v1.0.0
+ provider.pagerduty v1.2.0
+ provider.statuscake v0.2.0

Same issue occurs after upgrading to Terraform v0.11.8.

Affected Resource(s)

Please list the resources as a list, for example:

• pagerduty_extension

Terraform Configuration Files

resource "pagerduty_extension" "slack" {
  name              = "Slack"
  endpoint_url      = ""
  extension_schema  = "${data.pagerduty_extension_schema.slack.id}"
  extension_objects = ["${pagerduty_service.main.id}"]
}

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

resource "pagerduty_service" "main" {
  name = "Test"
  ...
}

Expected Behavior

No diff should have occurred with our various Slack extensions, as nothing has changed in our configuration or in our setup within PagerDuty.

There has been a pagerduty provider update which made changes to pagerduty_extension, but it is a minor release and so is expected to be backwards-compatible.

Actual Behavior

After upgrading to v1.2.0, we started receiving these diffs, which are attempting to remove our existing Slack extension configurations:

  ~ module.pagerduty.module.high_priority.pagerduty_extension.slack
      config: "{\"bot\":{\"bot_user_id\":\"UXXXXXXXX\"},\"incoming_webhook\":{\"channel\":\"#ops-alerts\",\"channel_id\":\"CXXXXXXXX\",\"configuration_url\":\"https://astute.slack.com/services/BXXXXXXXX\",\"url\":\"https://hooks.slack.com/services/TXXXXXXXX/BXXXXXXXX/xxxxxxxxxxxxxxxx\"},\"notify_types\":{\"acknowledge\":true,\"assignments\":true,\"resolve\":true},\"ok\":true,\"restrict\":\"pd-users\",\"scope\":\"identify,bot,incoming-webhook,channels:read,groups:read,im:read,users:read,users:read.email,chat:write:bot,groups:write\",\"team_id\":\"TXXXXXXXX\",\"team_name\":\"Test\",\"user_id\":\"UXXXXXXXX\"}" => ""

  ~ module.pagerduty.module.low_priority.pagerduty_extension.slack
      config: "{\"bot\":{\"bot_user_id\":\"UXXXXXXXX\"},\"incoming_webhook\":{\"channel\":\"#ops-alerts\",\"channel_id\":\"CXXXXXXXX\",\"configuration_url\":\"https://astute.slack.com/services/BXXXXXXXX\",\"url\":\"https://hooks.slack.com/services/TXXXXXXXX/BXXXXXXXX/xxxxxxxxxxxxxxxx\"},\"notify_types\":{\"acknowledge\":true,\"assignments\":true,\"resolve\":true},\"ok\":true,\"restrict\":\"pd-users\",\"scope\":\"identify,bot,incoming-webhook,channels:read,groups:read,im:read,users:read,users:read.email,chat:write:bot,groups:write\",\"team_id\":\"TXXXXXXXX\",\"team_name\":\"Test\",\"user_id\":\"UXXXXXXXX\"}" => ""

I'm in a hurry so haven't got time to properly look into it, but I thought I will just log this for now and downgrade our version until I can come back at look at it properly.

unable to use terraform-provider-pagerduty to create a Slack extension

$ terraform -v
Terraform v0.10.8

aws_provider_version = "1.9"
pagerduty_provider_version = "1.0"

Using the brand new pagerduty provider extension (thanks much for that!)
https://github.com/terraform-providers/terraform-provider-pagerduty/pull/69

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

resource "pagerduty_extension" "slack" {
  name = "name"
  endpoint_url = "https://hooks.slack.com/services/redacted"
  extension_schema = "${data.pagerduty_extension_schema.webhook.id}"
  extension_objects    = ["${pagerduty_service.service.id}"]
}

If I use the "Slack" pagerduty_extension_schema, Terraform creates a new extension. However the extension doesn't work (send messages to the appropriate slack channel) unless I authorize it in the Pagerduty console , and the icon in Pagerduty under Configuration / Extensions is broken (circle w/ a slash through it). If I then edit the new extension in Pagerduty, select the Slack channel, and authorize the extension, it will then work.

Questions -

1. how do I fully automate creating an extension? I don't see a way to authorize the extension and tell Pagerduty which slack channel to use for the notification using new extension
2. is there a way to use "Generic V2 Webhook" as a Slack extension? I'm just looking for a way to make this work easily, I don't need to use Generic V2 Webhook if the Slack extension will work.

"Generic V2 Webhook" pagerduty_extension_schema will create a new extension, but the extension won't work.

Also, I notice that we have older Slack extensions in Pagerduty with a "Slack (legacy webhook)" type
"Slack (Legacy Webhook)" pagerduty_extension_schema errors out with the following:
"data.pagerduty_extension_schema.webhook: Unable to locate any extension schema with the name: Slack (Legacy Webhook)"

thanks,
Dusty

Feature Request: Set default contact method

Terraform Version

Terraform v0.11.11
+ provider.pagerduty v1.2.1

Affected Resource(s)

Please list the resources as a list, for example:

• pagerduty_user
• pagerduty_user_contact_method

Terraform Configuration Files

N/A

Debug Output

Please provider a link to a GitHub Gist containing the complete debug output: https://www.terraform.io/docs/internals/debugging.html. Please do NOT paste the debug output in the issue; just paste a link to the Gist.

Panic Output

If Terraform produced a panic, please provide a link to a GitHub Gist containing the output of the crash.log.

Expected Behavior

Some support for setting preferred contact method for a User should be supported. It looks like the User has a default contact method, which I'd like to not be email and instead a phone call since that's more likely to be immediately noticeable.

Actual Behavior

It's just not supported

Steps to Reproduce

N/A

Important Factoids

My ideal scenario is that I could define a company-wide PagerDuty roster with everyone's preferred contact info in it so that in the case of our infrastructure's Cloudwatch Alarms going off, we'd be notified in the most direct way possible. For most of us, that's via a direct phone call. Currently, I'm able to create those Teams and Users for a project, but if I want to define the default contact method, I need to go through the PagerDuty website on a user-by-user basis.

References

N/A

Feature Request: Easily extract team members in escalation policies

Feature request

It would be nice if there was a resource available such as "pagerduty_team.teamname.members" that could be used to easily create escalation policies that include the whole team.

instead of having something like:

rule {
    escalation_delay_in_minutes = "5"

    target {
      type = "user_reference"
      id   = "${pagerduty_user.user1.id}"
    }

    target {
      type = "user_reference"
      id   = "${pagerduty_user.user2.id}"
    }

    target {
      type = "user_reference"
      id   = "${pagerduty_user.user3.id}"
    }

    target {
      type = "user_reference"
      id   = "${pagerduty_user.user4.id}"
    }

    target {
      type = "user_reference"
      id   = "${pagerduty_user.user5.id}"
    }
  }

It'd be nice if we could do something more like:

target {
  type = "team_reference"
  id = ${pagerduty_team.awesome.members}"

and have it interpolate the individual members of the team to include.

(I'm also open to suggestions if I'm missing an easy way to do this with the current provider. Ultimately, I'm trying to avoid defining teams, and then re-defining those teams as individual escalation targets. Seems like a lot of unnecessary duplication. Especially when you are doing this for multiple large teams)

pagerduty token interpolation from datasource broken

This issue was originally opened by @blalor as hashicorp/terraform#12708. It was migrated here as part of the provider split. The original body of the issue is below.

---

Terraform Version

Terraform v0.8.8

Affected Resource(s)

• pagerduty_user

Terraform Configuration Files

working config:

variable "pd_token" {}

provider "pagerduty" {
    token = "${var.pd_token}"
}

data "pagerduty_user" "me" {
    email = "[email protected]"
}

output "pd_user" {
    value = "${data.pagerduty_user.me.id}"
}

broken config:

variable "pd_token" {}

data "null_data_source" "local_vars" {
    inputs = {
        token = "${var.pd_token}"
    }
}

provider "pagerduty" {
    token = "${data.null_data_source.local_vars.inputs.token}"
}

data "pagerduty_user" "me" {
    email = "[email protected]"
}

output "pd_user" {
    value = "${data.pagerduty_user.me.id}"
}

Debug Output

terraform.txt

Expected Behavior

Should have gotten a successful (if ineffective) plan.

Actual Behavior

data.pagerduty_user.me: Refreshing state...
Error refreshing state: 1 error(s) occurred:

* data.pagerduty_user.me: Response did not contain formatted error: Could not decode JSON response: EOF. HTTP response code: 401. Raw response: &{Status:401 Unauthorized StatusCode:401 Proto:HTTP/1.1 ProtoMajor:1 ProtoMinor:1 Header:map[Connection:[keep-alive] X-Request-Id:[444f0bcbd1fc02a3ab93e8833c9e3c4c] Server:[nginx] Content-Type:[text/html; charset=utf-8] Status:[401 Unauthorized] X-Ua-Compatible:[IE=Edge,chrome=1] Cache-Control:[no-cache] Date:[Tue, 14 Mar 2017 22:01:56 GMT]] Body:0xc4201ce340 ContentLength:-1 TransferEncoding:[chunked] Close:false Uncompressed:false Trailer:map[] Request:0xc4200de300 TLS:0xc4200aa370}

Steps to Reproduce

1. terraform plan with broken config above.

pagerduty_service - Change in escalation_policy is not applied

This issue was originally opened by @MattHodge as hashicorp/terraform#14654. It was migrated here as part of the provider split. The original body of the issue is below.

---

Terraform Version

Terraform v0.9.5

Affected Resource(s)

• pagerduty_service

Terraform Configuration Files

Set a escalation_policy.

resource "pagerduty_service" "service" {
  name = "Some Service Name"
  auto_resolve_timeout = 14400
  acknowledgement_timeout = 600

  escalation_policy = "SOME-POLICYID"

  incident_urgency_rule {
    type    = "constant"
    urgency = "high"
  }
}

Change the escalation_policy.

resource "pagerduty_service" "service" {
  name = "Some Service Name"
  auto_resolve_timeout = 14400
  acknowledgement_timeout = 600

  escalation_policy = "SOME-NEW-POLICYID"

  incident_urgency_rule {
    type    = "constant"
    urgency = "high"
  }
}

Expected Behavior

The policy escalation_policy successfully changes

Actual Behavior

On terraform plan, it notices that the escalation_policy needs to change.

On terraform apply, it says it changed the escalation_policy, but it stays the same.

Issue with pagerduty_schedule and rotation_virtual_start

This issue was originally opened by @michaelcurran as hashicorp/terraform#11424. It was migrated here as part of the provider split. The original body of the issue is below.

---

Hi there,

I am trying to use pagerduty_schedule to set a weekly rotation and rotation_virtual_start to set a specific handoff time within the schedule.

Terraform Version

Terraform v0.8.4

Affected Resource(s)

• pagerduty_schedule

Terraform Configuration Files

resource "pagerduty_schedule" "something" {
  name      = "something"
  time_zone = "America/New_York"

  layer {
    name                         = "Layer 1"
    start                        = "2017-01-20T04:00:00-05:00"
    rotation_virtual_start       = "2017-01-20T16:00:00-05:00"
    rotation_turn_length_seconds = 604800

    users = [
      "${data.pagerduty_user.some_user.id}",
    ]
  }
}

Expected Behavior

Using rotation_virtual_start you should be able to adjust the schedule handoff time, and it should remain set to the specified time.

Actual Behavior

Once rotation_virtual_start has been set future changes to it are not detected during plans, and additional changes to the pagerduty_schedule resource, such as adding or removing users, cause the handoff time to change even though rotation_virtual_start has not been updated. I've noticed the change seems to decrease by 5 hours on each apply.

Steps to Reproduce

For rotation_virtual_start changes not being detected:

1. Create a pagerduty_schedule resource
2. terraform apply
3. Update rotation_virtual_start
4. terraform plan

For the handoff time being updated when not updating rotation_virtual_start:

1. Create a pagerduty_schedule resource
2. terraform apply
3. Check the schedule in PagerDuty
4. Add a user to the pagerduty_schedule resource (or add it directly within PagerDuty)
5. terraform apply (the handoff time for the schedule in PagerDuty should have changed)

Unable to disable acknowledgement_timeout and auto_resolve_timeout

Terraform Version

Terraform v0.10.8

Affected Resource(s)

pagerduty_service

Terraform Configuration Files

resource "pagerduty_service" "dan_test" {
  name = "Dan Test Service"
  escalation_policy = "P5SFKTX"
}

Debug Output

$ terraform apply
pagerduty_service.dan_test: Refreshing state... (ID: P8PH0G9)
pagerduty_service.dan_test: Modifying... (ID: P8PH0G9)
  acknowledgement_timeout: "1800" => "0"
  auto_resolve_timeout:    "14400" => "0"

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

Panic Output

n/a

Expected Behavior

Not changing the config, and doing an apply shouldn't modify the service, and the service should be created with disabled acknowledgement_timeout and auto_resolve_timeout.

Actual Behavior

According to the UI, auto_resolve_timeout is set to 4 hours, and acknowledgement_timeout is set to 30 minutes. They're not "disabled".

Additionally, terraform will think there is a need to "reset" these values to 0 when doing a plan or an apply.

Steps to Reproduce

1. terraform apply

Important Factoids

I attempted to force these values to null, nil and 0, but nothing has the desired effect of disabling these 2 values.

References

n/a

Please release a 0.2

Hey,

Pagerduty is pushing people to be using their v2 events API and to configure that with terraform we need to have a released version of #40.

Can you please make a new release please.

Thanks

No option to set "overflow" flag while creating/updating a schedule

Hi there,

Terraform Version

terraform_0.9.8

Affected Resource(s)

• pagerduty_schedule

Terraform Configuration Files

 resource "pagerduty_schedule" "example1" {
  name      = "Daily Engineering Rotation"
  time_zone = "America/Los_Angeles"

  layer {
    name                         = "Shift1"
    start                        = "2017-06-26T15:00:00"
    rotation_virtual_start       = "2017-06-26T15:00:00"
    rotation_turn_length_seconds = 259200
    users                        = ["${pagerduty_user.user1.id}"]
}
}

Expected Behavior

Would expect schedule didn't change since it was set once
To fix this issue the flag overflow=true needs to be passed. according to the PD doc https://v2.developer.pagerduty.com/v2/page/api-reference#!/Schedules/put_schedules_id

Any on-call schedule entries that pass the date range bounds will be truncated at the bounds, unless the parameter overflow=true is passed. This parameter defaults to false. For instance, if your schedule is a rotation that changes daily at midnight UTC, and your date range is from 2011-06-01T10:00:00Z to 2011-06-01T14:00:00Z:

• If you don't pass the overflow=true parameter, you will get one schedule entry returned with a start of 2011-06-01T10:00:00Z and end of 2011-06-01T14:00:00Z.
• If you do pass the overflow=true parameter, you will get one schedule entry returned with a start of 2011-06-01T00:00:00Z and end of 2011-06-02T00:00:00Z.

Actual Behavior

Schedule changed after every terraform apply command gets run

Steps to Reproduce

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

1. Create a schedule
2. Have list of users in the order they should be on-call
3. Run terraform apply
4. Login into PD, see the schedule got shifted (updated)

5 Run terraform apply again

Important Factoids

From PD documentation

Schedules updated all the time

Hi,
Schedules are changed each time I launch terraform apply:

pagerduty_schedule.x1: Modifying... (ID: PV7K7DF)
  layer.0.rotation_virtual_start: "2018-05-08T06:00:00+02:00" => "2018-05-07T09:00:00-19:00"
pagerduty_schedule.x2: Modifying... (ID: PK5IN77)
  layer.0.rotation_virtual_start: "2018-05-08T06:00:00+02:00" => "2018-05-07T09:00:00-19:00"
pagerduty_schedule.x3: Modifying... (ID: P4S7NMR)
  layer.0.rotation_virtual_start: "2018-05-08T06:00:00+02:00" => "2018-05-07T09:00:00-19:00"
pagerduty_schedule.x4: Modifying... (ID: PUFJM04)
  layer.0.rotation_virtual_start: "2018-05-08T06:00:00+02:00" => "2018-05-07T09:00:00-19:00"
  layer.0.start:                  "2018-05-22T14:41:54+02:00" => "2018-05-11T09:00:00-19:00"

Did I missed something?

Terraform Version

 Terraform v0.11.7
+ provider.pagerduty v1.1.0

Affected Resource(s)

• pagerduty_schedule

Terraform Configuration Files

Configuration of one of them:

resource "pagerduty_schedule" "x1" {
  name      = "Weekly Backend Rotation"
  time_zone = "Europe/Paris"

  layer {
    name                         = "Day Shift"
    start                        = "2018-05-11T09:00:00-19:00"
    rotation_virtual_start       = "2018-05-07T09:00:00-19:00"
    rotation_turn_length_seconds = 604800
    users                        = ["${pagerduty_user.user1.id}", "${pagerduty_user.user2.id}"]
``

### Expected Behavior
Nothing.

### Actual Behavior
Schedules are updated.

Vendor Data Source can't find Sentry

The following configuration doesn't find the Vendor "Sentry," but instead "IPSentry," obliging me to instead put the Sentry vendor's id in a local.

data "pagerduty_vendor" "sentry" {
  name = "Sentry"
}

I haven't looked at the code, but I have looked at the PagerDuty API. Running curl -X GET --header 'Accept: application/vnd.pagerduty+json;version=2' --header 'Authorization: Token token=<your token>' 'https://api.pagerduty.com/vendors?query=Sentry' gives back both vendors, with IPSentry first.

{
  "vendors": [
    {
      "id": "PY3OLY6",
      "type": "vendor",
      "summary": "IPSentry",
      "self": "https://api.pagerduty.com/vendors/PY3OLY6",
      "html_url": null,
      "name": "IPSentry",
      "website_url": "http://ipsentry.com/",
      "long_name": "IPSentry",
      "logo_url": "",
      "thumbnail_url": "",
      "description": "IPSentry is a Windows based network monitoring software package used by thousands of information system specialists, system administrators, and IT solution providers around the world.",
      "integration_guide_url": "https://www.pagerduty.com/docs/guides/ipsentry-integration-guide/",
      "connectable": false,
      "generic_service_type": "api",
      "alert_creation_default": "create_alerts_and_incidents",
      "alert_creation_editable": true,
      "is_pd_cef": false
    },
    {
      "id": "PKG4M95",
      "type": "vendor",
      "summary": "Sentry",
      "self": "https://api.pagerduty.com/vendors/PKG4M95",
      "html_url": null,
      "name": "Sentry",
      "website_url": "https://getsentry.com/welcome/",
      "long_name": "Sentry",
      "logo_url": "https://s3.amazonaws.com/pdpartner/sentry_large.png",
      "thumbnail_url": "https://s3.amazonaws.com/pdpartner/sentry_thumb.png",
      "description": "Sentry provides real-time crash reporting for your web apps, mobile apps, and games.",
      "integration_guide_url": "https://www.pagerduty.com/docs/guides/sentry-integration-guide/",
      "connectable": false,
      "generic_service_type": "api",
      "alert_creation_default": "create_alerts_and_incidents",
      "alert_creation_editable": true,
      "is_pd_cef": false
    }
  ],
  "query": "Sentry",
  "limit": 25,
  "offset": 0,
  "total": null,
  "more": false
}

I think it'd be a good idea to find the object with the matching name field in the array, rather than just taking the first one. This would also require users to specify the full, exact name of the vendor in the data source's name, which is what I assumed was the case from the start; as it stands, I get the same results using "Sen".

New Release v1.3.0

There is a bug fix in master that will get us past a showstopper for our use case. Can you please release v1.3.0 or is a release date planned?

Pagerduty provider does not support email management rules

This issue was originally opened by @fromonesrc as hashicorp/terraform#12925. It was migrated here as part of the provider split. The original body of the issue is below.

---

On the pagerduty_service_integration when choosing the generic_email_inbound_integration integration type, there is no option to configure the email management rules so it defaults to "Open a new incident for each trigger email" which results in noisy pagers.

New service created with terraform did not show up in my team

It seems like the newly created pagerduty_service did not show up in my team.

I dont think I had issue ebfore for creating the pagerduty_service resources before.

Also going to file a PD support ticket.

Add support for global event rules

Add support for global event rules More info

[Enhancement] pagerduty_team data source

Hi,

we've upgraded to standard and have found it to be much nicer to introduce terraform at the boundary of the teams. Meaning, we we want to create teams, schedules, users etc. by hand, but want to create services, service integrations etc. using terraform.

This is currently impossible without first performing an import of an existing resource. We'd much rather be able to just create new services and escalation policies using a data resource instead of a resource.. ehrm.. resource.

In short we'd like this:

data "pagerduty_team" "team" {
    name = "${var.team_name}"
}

Terraform Version

Run terraform -v to show the version. If you are not running the latest version of Terraform, please upgrade because your issue may have already been fixed.

Terraform v0.11.3

• provider.aws v1.9.0
• provider.pagerduty v0.1.3

Feature Request: Ability to assign a Team to a Service

According to the docs (https://v2.developer.pagerduty.com/v2/page/api-reference#!/Services/put_services_id) it's possible to assign Teams directly to a Service. This isn't possible with the Terraform PagerDuty Provider but should be possible and valuable.

r/service_integration support to output html_url

Currently, the service integration doesn't output the Integration URL (known by the API as html_url). This URL would be handy for subscribing SNS HTTPS notifications (for example).

PR forthcoming...

Error [Url can't be empty] with resource "pagerduty_extension"

Terraform Version

Terraform v0.11.13

Affected Resource(s)

pagerduty_extension

Terraform Configuration Files

resource "pagerduty_extension" "slack"{
  name = "My Web App Extension"
   extension_schema = "${data.pagerduty_extension_schema.webhook.id}"
  extension_objects    = ["${pagerduty_service.example.id}"]

  config = <<EOF
{
    "restrict": "any",
    "notify_types": {
            "resolve": false,
            "acknowledge": false,
            "assignments": false
    },
    "access_token": "XXX"
}
EOF

}.

Here is the full code:
https://github.com/heldersepu/hs-scripts/blob/master/TerraForm/pagerduty/pagerduty.tf

Debug Output

Error: Error applying plan:

1 error(s) occurred:

* ....pagerduty_extension.slack: 1 error(s) occurred:

* pagerduty_extension.slack: 
  POST API call to https://api.pagerduty.com/extensions failed 400 Bad Request. 
  Code: 2001, Errors: [Url can't be empty], Message: Invalid Input Provided

Expected Behavior

It should complete without errors?

Actual Behavior

We get that strange 'Url can't be empty' error but according to the documentation the endpoint_url is optional

User with base role of observer, but team role of manager cannot manage schedules in with Terraform

Terraform Version

% terraform -v
Terraform v0.11.4
+ provider.pagerduty v1.2.1

Affected Resource(s)

• pagerduty_schedule

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

terraform {
  required_version = "~> 0.11.4"
}

variable "pagerduty_token" {}
variable "team_name" {}
variable "user_email" {}

provider "pagerduty" {
  version = "~> 1.0"
  token   = "${var.pagerduty_token}"
}

data "pagerduty_team" "test" {
  name = "${var.team_name}"
}

data "pagerduty_user" "test" {
  email = "${var.user_email}"
}

resource "pagerduty_schedule" "oncall" {
  name        = "Test Oncall"
  description = "Managed by Terraform"
  time_zone   = "America/New_York"

  layer {
    name                         = "24/7"
    start                        = "2019-03-13T09:00:00-05:00"
    rotation_virtual_start       = "2019-03-13T09:00:00-05:00"
    rotation_turn_length_seconds = "1209600" // 14 * 24 * 60 * 60
    users                        = [
      "${data.pagerduty_user.test.id}",
    ]
  }
}

Expected Behavior

A successful apply that creates a schedule for the team.

Actual Behavior

A failed apply with a 403 Access Denied error.

* pagerduty_schedule.oncall: 1 error(s) occurred:

* pagerduty_schedule.oncall: POST API call to https://api.pagerduty.com/schedules failed 403 Forbidden. Code: 2010, Errors: <nil>, Message: Access Denied

Steps to Reproduce

1. Create a team and a user assigned to that team
2. Set the user's base role to 'observer' and their role on the team as 'manager'
3. Generate an API key for the user and use it to configure the pagerduty provider.
4. Provide the team name and user email from step 1 as the team_name and user_name variables.
5. terraform apply

Important Factoids

When I'm setting up a schedule in the GUI. I'm required to choose a team from a drop down menu (screenshot below). However, there's no equivalent requirement documented in the Pagerduty provider's docs.

Incident Timeouts in Services

Hi,

There is no possibility to disabled Acknowledgement timeout and Auto-resolution in Services:

Do you plan to work on this feature?

Reasons to not use Pagerduty's go-pagerduty client

Affected Resource(s)

All

Important Factoids

terraform-provider-pagerduty currently makes use of a go-pagerduty client from heimweh (ref: https://github.com/heimweh/go-pagerduty ), however there is a different official Pagerduty go-pagerduty client (ref: https://github.com/PagerDuty/go-pagerduty).

• Is there an official reason to use an unofficial client where an official one exists?
• If so, could we please make not in the README.md?
• If not, is it worthwhile investigating the requirements to migrate to the officially released client for a v0.2.0 release?

forced recreation of pagerduty_schedule not working propperly

Terraform Version

Terraform v0.10.7
Compiled the pagerduty module manually from master to work around bug go version <1.9

Affected Resource(s)

Please list the resources as a list, for example:

• pagerduty_schedule

When I remove a layer from a schedule, terraform forces a new resource. Unfortunately, if the schedule is in use in a policy (which is also controlled by terraform), it cannot remove the schedule as it is still in use.

I would expect the escalation policy to remove the schedule, then the old schedule to be removed and a new one to be created and assigned to the policy.

Provider is incompatible with terraform version 0.12.0

The pagerduty provider doesn't work with the latest release of Terraform.

Terraform Version

0.12.0

Affected Resource(s)

• provider "pagerduty"

Terraform Configuration Files

variable "pagerduty_token" {
  description = "The PagerDuty api token"
}

provider "pagerduty" {
  token = "${var.pagerduty_token}"
}

# Service for the lambda
resource "pagerduty_service" "our-service" {
  name                    = "Service name"
  description             = "Service description"
  escalation_policy       = "PA8LWK9"
  alert_creation          = "create_alerts_and_incidents"

  incident_urgency_rule {
    type = "constant"
    urgency = "high"
  }
}

resource "pagerduty_service_integration" "grafana" {
  service = "${pagerduty_service.our-service.id}"
  name = "Grafana"
  type = "events_api_v2_inbound_integration"
}

Expected Behavior

The service and grafana integration should have been created.

Actual Behavior

The following error was received

Initializing provider plugins...
- Checking for available provider plugins...

No available provider "pagerduty" plugins are compatible with this Terraform version.

From time to time, new Terraform major releases can change the requirements for
plugins such that older plugins become incompatible.

Terraform checked all of the plugin versions matching the given constraint:
    (any version)

Unfortunately, none of the suitable versions are compatible with this version
of Terraform. If you have recently upgraded Terraform, it may be necessary to
move to a newer major release of this provider. Alternatively, if you are
attempting to upgrade the provider to a new major version you may need to
also upgrade Terraform to support the new version.

Consult the documentation for this provider for more information on
compatibility between provider versions and Terraform versions.


Error: no available version is compatible with this version of Terraform

Steps to Reproduce

1. terraform apply

PageDuty how to create service Extension via terraform

Hi ,

Can't find the way to create Extensions via terraform
I'm trying to setup slack extension instead using webhook .

Terraform Version

Terraform v0.9.8

Affected Resource(s)

Was checking docs here: https://www.terraform.io/docs/providers/pagerduty/r/service_integration.html

Thank you for the help,
N

Feature request: Override resource

The PagerDuty API allows you to define schedule overrides. This is useful for teams that need to have less homogenous schedules (eg, weekends that can't just rotate regularly because of inconsistent travel plans).

I'd love to use Terraform as the main interface for defining our schedules via git. That would require terraform-provider-pagerduty to have a resource for overrides.

I think it probably makes the most sense to have it as a standalone resource rather than just an array on schedules.

Feature: Make attribute start_day_of_week accept an array of days.

terraform 0.11.3
pagerduty provider: 1.2.1

It would be really cool if restriction 'weekly_restriction' could accept array of days in start_day_of_week. My use case is that we have different support hours during the week and different at weekends. Currently I had to do 7 restrictions, one per day:

restriction {
  type              = "weekly_restriction"
  start_time_of_day = "07:00:00"
  duration_seconds  = 54000
  start_day_of_week = 1
}

restriction {
  type              = "weekly_restriction"
  start_time_of_day = "07:00:00"
  duration_seconds  = 54000
  start_day_of_week = 2
}

restriction {
  type              = "weekly_restriction"
  start_time_of_day = "07:00:00"
  duration_seconds  = 54000
  start_day_of_week = 3
}

restriction {
  type              = "weekly_restriction"
  start_time_of_day = "07:00:00"
  duration_seconds  = 54000
  start_day_of_week = 4
}

restriction {
  type              = "weekly_restriction"
  start_time_of_day = "07:00:00"
  duration_seconds  = 54000
  start_day_of_week = 5
}

restriction {
  type              = "weekly_restriction"
  start_time_of_day = "09:00:00"
  duration_seconds  = 43200
  start_day_of_week = 6
}
restriction {
  type              = "weekly_restriction"
  start_time_of_day = "09:00:00"
  duration_seconds  = 43200
  start_day_of_week = 7
}

What I think would be very cool:

restriction {
  type              = "weekly_restriction"
  start_time_of_day = "07:00:00"
  duration_seconds  = 54000
  start_day_of_week = [1,2,3,4,5]
}
restriction {
  type              = "weekly_restriction"
  start_time_of_day = "09:00:00"
  duration_seconds  = 43200
  start_day_of_week = [6,7]
}

This would simplify .tf file quite a bit.

Thanks!

[Enhancement] Service Extensions

It would be awesome to be able to add service extensions via Terraform (for example, reporting to Slack).

API Reference is here: https://v2.developer.pagerduty.com/v2/page/api-reference#!/Extensions/get_extensions

Fail to create PagerDuty Schedule with Weekly Restriction

This issue was originally opened by @koebane as hashicorp/terraform#11135. It was migrated here as part of the provider split. The original body of the issue is below.

---

Hi there,

I am trying to create a pager duty schedule that utilizes weekly restrictions. An error gets returned because the PagerDuty API requires start_day_of_week parameter for weekly restrictions but terraform doesn't allow for that parameter according to https://www.terraform.io/docs/providers/pagerduty/r/schedule.html.

Even though the terraform API doesn't acknowledge the start_day_of_week parameter, I tried including it as well.

Terraform Version

Terraform v0.8.3

Affected Resource(s)

pagerduty_schedule

Without start_day_of_week parameter

Terraform Configuration Files

variable "user_id" {
  type = "map"
  default = {
    user1 = "PD85ZRB"
    user2 = "PQP8L2Y"
    user3  = "P3DX8AA"
  }
}

provider "pagerduty" {
    token = "6TksacesvefcwWp83zxiT"
}

resource "pagerduty_schedule" "my_schedule" {
  name = "${var.name_prefix} Production Weekly Schedule Rotation"
  time_zone = "America/New_York"

  layer {
    name                          = "Evening and Weekend Shift"
    rotation_turn_length_seconds  = 604800 # weekly
    start                         = "2017-01-10T17:00:00-06:00"
    rotation_virtual_start        = "2017-01-06T17:00:00-06:00"
    users                         = [ "${var.user_id["user1"]}", "${var.user_id["user2"]}"]

    restriction {
      type              = "weekly_restriction"
      start_time_of_day = "17:00:00"
      duration_seconds  =  57600  
    }
    restriction {
      type              = "weekly_restriction"
      start_time_of_day = "17:00:00"
      duration_seconds  =  57600  
    }
    restriction {
      type              = "weekly_restriction"
      start_time_of_day = "17:00:00"
      duration_seconds  =  57600  
    }
    restriction {
      type              = "weekly_restriction"
      start_time_of_day = "17:00:00"
      duration_seconds  =  57600  
    }
    restriction {
      type              = "weekly_restriction"
      start_time_of_day = "17:00:00"
      duration_seconds  =  604800  
    }
  }

  layer {
    name                          = "Day and Work Shifts"
    rotation_turn_length_seconds  = 86400 # Daily
    start                         = "2017-01-10T11:54:16-06:00"
    rotation_virtual_start        = "2017-01-10T09:00:00-06:00"
    users                         = [ "${var.user_id["user1"]}", "${var.user_id["user2"]}", "${var.user_id["user3"]}"]
    
    restriction {
      type              = "daily_restriction"
      start_time_of_day = "09:00:00"
      duration_seconds  =  28800
    }
  }
}

Actual Behavior without start_day_of_week parameter

Error returned

Error applying plan:

1 error(s) occurred:

* pagerduty_schedule.my_schedule: Failed call API endpoint. HTTP response code: 400. Error: &{2001 Invalid Input Provided [Weekly Restriction must contain a Start Day of Week]}

With start_day_of_week parameter

Terraform Configuration Files

variable "user_id" {
  type = "map"
  default = {
    user1 = "PD85ZRB"
    user2 = "PQP8L2Y"
    user3  = "P3DX8AA"
  }
}

provider "pagerduty" {
    token = "6TksacesvefcwWp83zxiT"
}

resource "pagerduty_schedule" "my_schedule" {
  name = "${var.name_prefix} Production Weekly Schedule Rotation"
  time_zone = "America/New_York"

  layer {
    name                          = "Evening and Weekend Shift"
    rotation_turn_length_seconds  = 604800 # weekly
    start                         = "2017-01-10T17:00:00-06:00"
    rotation_virtual_start        = "2017-01-06T17:00:00-06:00"
    users                         = [ "${var.user_id["user1"]}", "${var.user_id["user2"]}"]

    restriction {
      type              = "weekly_restriction"
      start_time_of_day = "17:00:00"
      duration_seconds  =  57600
      start_day_of_week = "1"  
    }
    restriction {
      type              = "weekly_restriction"
      start_time_of_day = "17:00:00"
      duration_seconds  =  57600 
      start_day_of_week = "2"   
    }
    restriction {
      type              = "weekly_restriction"
      start_time_of_day = "17:00:00"
      duration_seconds  =  57600
      start_day_of_week = "3"    
    }
    restriction {
      type              = "weekly_restriction"
      start_time_of_day = "17:00:00"
      duration_seconds  =  57600
      start_day_of_week = "4"    
    }
    restriction {
      type              = "weekly_restriction"
      start_time_of_day = "17:00:00"
      duration_seconds  =  604800
      start_day_of_week = "5"    
    }
  }

  layer {
    name                          = "Day and Work Shifts"
    rotation_turn_length_seconds  = 86400 # Daily
    start                         = "2017-01-10T11:54:16-06:00"
    rotation_virtual_start        = "2017-01-10T09:00:00-06:00"
    users                         = [ "${var.user_id["user1"]}", "${var.user_id["user2"]}", "${var.user_id["user3"]}"]
    
    restriction {
      type              = "daily_restriction"
      start_time_of_day = "09:00:00"
      duration_seconds  =  28800
    }
  }
}

Actual Behavior start_day_of_week parameter

Error returned

Error applying plan:

1 error(s) occurred:

* pagerduty_schedule.my_schedule: Response did not contain formatted error: Could not decode JSON response: json: cannot unmarshal object into Go value of type []string. HTTP response code: 400. Raw response: &{Status:400 Bad Request StatusCode:400 Proto:HTTP/1.1 ProtoMajor:1 ProtoMinor:1 Header:map[Access-Control-Allow-Methods:[GET, POST, PUT, DELETE, OPTIONS] Access-Control-Allow-Origin:[*] Access-Control-Allow-Headers:[Authorization, Content-Type] X-Ua-Compatible:[IE=Edge,chrome=1] Date:[Tue, 10 Jan 2017 18:51:55 GMT] Connection:[keep-alive] Status:[400 Bad Request] Access-Control-Max-Age:[1728000] Cache-Control:[no-cache] X-Request-Id:[70b9b14be473c73684a3c69e478671f0] Server:[nginx] Content-Type:[application/json; charset=utf-8]] Body:0xc4204edc40 ContentLength:-1 TransferEncoding:[chunked] Close:false Uncompressed:false Trailer:map[] Request:0xc4205e7860 TLS:0xc4201b56b0}

Expected Behavior

One would expect a schedule be created.

Steps to Reproduce

1. terraform apply

Invalid Input Provided [Integration email cannot be empty.]}

Hi ,
Maybe an easy question, but I'm relatively new to terraform.
Please help to resolve below error with Zendesk resource pagerduty_service_integration

Terraform Version

Terraform v0.9.8

Affected Resource(s)

Generated after terraform apply command

data "pagerduty_vendor" "zendesk" {
  name = "zendesk"
}

resource "pagerduty_service_integration" "PartnerAssistance-zendesk" {
  name    = "${data.pagerduty_vendor.zendesk.name}"
  service = "${pagerduty_service.PartnerAssistance.id}"
  vendor  = "${data.pagerduty_vendor.zendesk.id}"
}

Debug Output

Error applying plan:

1 error(s) occurred:

* pagerduty_service_integration.PartnerAssistance-zendesk: 1 error(s) occurred:

* pagerduty_service_integration.PartnerAssistance-zendesk: Failed call API endpoint. HTTP response code: 400. Error: &{2001 Invalid Input Provided [Integration email cannot be empty.]}

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

Expected Behavior

I'm not sure where do I add the email in my JInja2 template to get rid of this message Integration email cannot be empty ?

Steps to Reproduce

1. Creating PD integration with Jinja2. Everything works fine, except zendesk integration.

resource "pagerduty_service_integration" "{{ team }}-{{ vendor }}" {
  name    = "${data.pagerduty_vendor.{{ vendor }}.name}"
  service = "${pagerduty_service.{{ team }}.id}"
  vendor  = "${data.pagerduty_vendor.{{ vendor }}.id}"
}

2 . After I ran terraform apply everything ran just fine. But seems like zendesk integration is failed. But I can't find how to add email to the template. No example here as well https://www.terraform.io/docs/providers/pagerduty/r/service_integration.html

Thank you,
N

html_url attribute on pagerduty_service_integration is not the Integration URL

Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

> terraform -v
Terraform v0.11.4
+ provider.pagerduty v1.0.0
+ provider.template v1.0.0

Affected Resource(s)

• pagerduty_service_integration

Terraform Configuration Files

resource "pagerduty_service_integration" "prod_splunk" {
  name            = "${data.pagerduty_vendor.splunk.name}"
  service         = "${pagerduty_service.art_prod.id}"
  vendor          = "${data.pagerduty_vendor.splunk.id}"
  integration_key = "[redacted]"
}

output "prod_splunk" {
  value = "${pagerduty_service_integration.prod_splunk.html_url}"
}

Expected Behavior

Accodring to the docs:

html_url - Configure your events to send webhooks to this endpoint. This is described as Integration URL in some Pagerduty documentation.

The prod_splunk output should've contained a value like https://events.pagerduty.com/integration/[redacted_key]/enqueue

Actual Behavior

The prod_splunk output contained a value like https://dealer.pagerduty.com/services/[redacted]/integrations/[redacted].

Visiting this url takes me to the page where I can see the actual integration_url.

Permadiff on schedule start time

Terraform Version

0.10.2

(This was not an issue on 0.9.10. It became an issue after upgrading.)

Affected Resource(s)

• pagerduty_schedule

Terraform Configuration Files

resource "pagerduty_schedule" "our_primary_on_call" {
  name      = "Our Primary On-call"
  time_zone = "America/Chicago"

  layer {
    start                        = "2017-08-08T17:16:03-05:00" # Rotation flips at 11AM Mon, Chi time
    rotation_virtual_start       = "2017-07-31T11:00:00-05:00"
    rotation_turn_length_seconds = 604800                      # 1 week

    users = ["${data.pagerduty_user.on_call_users.*.id}"]
  }
}

Debug Output

I can provide an isolated example and produce debug output if necessary but would rather not have to do so and then also redact our private credentials.

Expected Behavior

No diff should be produced after applying this once

Actual Behavior

Subsequent plans, applies show a diff:

  ~ module.pagerduty.pagerduty_schedule.our_primary_on_call
      layer.0.start: "2017-08-23T15:09:35-05:00" => "2017-08-08T17:16:03-05:00"

Steps to Reproduce

1. terraform apply
2. terraform plan

'ignore_changes' to field 'layer' in pagerduty_schedule is not respected.

When creating a pagerduty_schedule resource with a list of users in the layer attribute, any drifting from what is in terraform vs. pagerduty will trigger terraform to overwrite it in spite of adding

lifecycle {
  ignore_changes = ["layer"]
}

to the resource. Is this in issue with the ignore_changes implementation in terraform or is this something the pagerduty provider is not respecting?

Terraform Version

Run terraform -v to show the version. If you are not running the latest version of Terraform, please upgrade because your issue may have already been fixed.

Terraform v0.11.6

Affected Resource(s)

Please list the resources as a list, for example:

• pagerduty_schedule

Terraform Configuration Files

resource "pagerduty_user" "user" {
  name  = "Earline Greenholt"
  email = "[email protected]"
}

resource "pagerduty_schedule" "team" {
  lifecycle {
    ignore_changes = ["layer"]
  }

  time_zone   = "Europe/Copenhagen"
  name        = "Schedule"
  description = "$schedule covering all working-hours for all weekdays'"

  layer {
    name                         = "Working Hours"
    start                        = "2018-05-03T13:00:00+02:00"
    rotation_virtual_start       = "2018-05-03T13:00:00+02:00"
    rotation_turn_length_seconds = 604800
    users                        = ["${pagerduty_user.user.id}"]

    # monday
    restriction {
      type              = "weekly_restriction"
      start_time_of_day = "09:00:00"
      duration_seconds  = 28800
      start_day_of_week = 1
    }
  }
}

Debug Output

Please provider a link to a GitHub Gist containing the complete debug output: https://www.terraform.io/docs/internals/debugging.html. Please do NOT paste the debug output in the issue; just paste a link to the Gist.

Panic Output

If Terraform produced a panic, please provide a link to a GitHub Gist containing the output of the crash.log.

Expected Behavior

I should have seen an update to the time_zone for two of the resources, and that is it.

Actual Behavior

The changes to the previously created users is not being ignored.

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place
  - destroy

Terraform will perform the following actions:

  ~ module.consumer-team.pagerduty_schedule.team
      layer.0.users.0: "P1HYGEM" => "PLP5Z2D"

  ~ module.ecomm.pagerduty_schedule.team
      layer.0.users.0: "PO5CYWA" => "PLP5Z2D"
      time_zone:       "Europe/Copenhagen" => "Europe/Vilnius"

  ~ module.enforcement.pagerduty_schedule.team
      layer.0.users.0: "PGA7BYW" => "PLP5Z2D"
      time_zone:       "Europe/Copenhagen" => "Europe/Vilnius"

  ~ module.product-reviews.pagerduty_schedule.team
      layer.0.users.0: "PC47IF2" => "PLP5Z2D"


Plan: 0 to add, 4 to change, 2 to destroy.

Steps to Reproduce

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

1. terraform apply
2. go into pagerduty and edit the users on the schedule (I replaced default user in this case with a specific user from a team)
3. terraform plan

Changing a PagerDuty service's support hours or scheduled actions recreates the service

Changing a PagerDuty service's support hours or scheduled actions recreates the service.

This appears to be intentional as the docs state

Changes to support_hours necessitate re-creating the service resource.

and

Changes [to scheduled actions] necessitate re-createing the service resource.

Re-creating a service under these circumstances causes us problems:

• we need to update our systems to post alerts to a new endpoint
• we lose alert history

It appears that this behaviour is controlled through hard-coded true values for support hours and scheduled actions. If I was to change these to false, what, if anything would break? My initial testing indicates it seems okay when adding support hours or scheduled actions entities to a service, updating them, or removing them from a service.

This is currently a blocker for us so I'm more than happy to put together a pull request if you can point me in the right direction.

Crash on pagerduty_service_integration import

This issue was originally opened by @micahhausler as hashicorp/terraform#14794. It was migrated here as part of the provider split. The original body of the issue is below.

---

Terraform Version

$ terraform -v
Terraform v0.9.5

Affected Resource(s)

I was trying to import a pagerduty pagerduty_service_integration, and consistently get a crash. I has just imported a pagerduty_service successfully.

Terraform Configuration Files

# /pagerduty/main.tf
resource "pagerduty_service" "elastalert" {
  name                    = "Elastalert"
  description             = "Elastalert service"
  auto_resolve_timeout    = 14400
  acknowledgement_timeout = 1800
  escalation_policy       = "${pagerduty_escalation_policy.security.id}"

  incident_urgency_rule {
    type    = "constant"
    urgency = "high"
  }
}

resource "pagerduty_service_integration" "elastalert_test" {
  name    = "API - Test"
  type    = "generic_events_api_inbound_integration"
  service = "${pagerduty_service.elastalert.id}"
}

# /environments/pagerduty/main.tf
variable "pagerduty_token" {}

provider "pagerduty" {
  token = "${var.pagerduty_token}"
}

module "pagerduty" {
  source = "../../pagerduty/"
}

terraform {
  backend "atlas" {
    name = "skuid/pagerduty"
  }
}

Debug Output

https://gist.github.com/micahhausler/c1cdbb3f752d4210b809ebf149fd8736
(second file in the gist)

Panic Output

https://gist.github.com/micahhausler/c1cdbb3f752d4210b809ebf149fd8736
(first file in the gist)

Expected Behavior

The import would work

Actual Behavior

terraform crashed

Steps to Reproduce

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

1. terraform import -var-file prod.tfvars module.pagerduty.pagerduty_service_integration.elastalert_test <id>

Important Factoids

$ uname -a
Darwin Micahs-MacBook-Pro-4.local 16.5.0 Darwin Kernel Version 16.5.0: Fri Mar  3 16:52:33 PST 2017; root:xnu-3789.51.2~3/RELEASE_X86_64 x86_64