PagerDuty / terraform-provider-pagerduty

Terraform PagerDuty provider
https://www.terraform.io/docs/providers/pagerduty/
Mozilla Public License 2.0
206 stars 210 forks source link

pagerduty_escalation_policy implicitly associates users with team but does not clean up #285

Open awendt opened 3 years ago

awendt commented 3 years ago

Hi there,

Terraform Version

0.12.28

Affected Resource(s)

Terraform Configuration Files

resource "pagerduty_schedule" "on-call" {
  name        = "Some schedule"
  description = "Some schedule"
  time_zone   = "Europe/Berlin"
  layer {
    name = "Layer 1"
    start = "2020-12-03T23:00:00+01:00"
    rotation_virtual_start = "2020-12-03T23:00:00+01:00"

    rotation_turn_length_seconds = 604800 # 1 week
    users = [
      pagerduty_user.alice.id,
    ]
    restriction {
      type              = "weekly_restriction"
      start_day_of_week = 1 # Monday
      start_time_of_day = "10:00:00"
      duration_seconds  = 5400 # 1.5 hours => till 11:30:00
    }
  }
}

resource "pagerduty_escalation_policy" "ateam" {
  name        = "A Team"
  description = "A Team"
  teams       = [pagerduty_team.ateam.id]

  rule {
    target {
      type = "schedule_reference"
      id   = pagerduty_schedule.on-call.id
    }

    escalation_delay_in_minutes = 20
  }

  rule {
    target {
      type = "user_reference"
      id   = pagerduty_user.bob.id
    }

    escalation_delay_in_minutes = 60
  }
}

Expected Behavior

Because pagerduty_escalation_policy.ateam implicitly creates a team membership for pagerduty_user.alice and pagerduty_user.bob, we expect the destruction of resource pagerduty_escalation_policy.ateam to clean up those implicitly created team memberships.

Actual Behavior

The above configuration associates both pagerduty_user.alice and pagerduty_user.bob with the team pagerduty_team.ateam but fails to remove the association when pagerduty_escalation_policy.ateam is destroyed.

This means the provider creates resources that are not reflected in state. The provider creates resources that are left dangling after resource destruction.

APIs should not have side effects (in this case, "associating people with teams"), or the side effects should be consistent on CREATE and DELETE.

Steps to Reproduce

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

  1. terraform apply
  2. Remove pagerduty_escalation_policy.ateam from configuration
  3. terraform apply
  4. In UI, navigate to team and observe the team members.

References

jjm commented 3 years ago

I expect this is happening on the server side at PagerDuty and not via Terraform, as being added to an escalation policy even via the WebUI results in this addition. The only way I've found around this is to add the user at as a responder (or manager) explicitly in Terraform so that you can remove the user from the team when removing from the escalation policy.

You'll also have issues on user removal if you don't manage all schedules via Terraform.

crablab commented 6 months ago

I think we have a variant of this issue. Because we were aware of the implicit change PagerDuty makes under the hood, adding users to a team if they're in a schedule, we manually add & remove users from teams using the pagerduty_team_membership in a separately to pagerduty_schedule.

However, even when doing this the provider will still try to remove pagerduty_team_membership before adjusting the members in pagerduty_schedule layers. Adding depends_on to try and force the ordering doesn't seem to do anything either.