Schedule#start challenge

[ghost]

Summary

I challenge the [schedule#start] (https://registry.terraform.io/providers/PagerDuty/pagerduty/latest/docs/resources/schedule#start) (maybe one can also say I do not understand how it works).

How can a property be required but then immediately be overridden by PD API?

I can not see through 100%. Also, why should one really literally care about the start, the rotation_virtual_start matters.

Current behaviour

start behaves arbitrarily. To me it even seems that if someone creates an override for the schedule under inspection, the start date changes.

Wanted behaviour

• start is not required and not required
• if PD API needs start the provider spawns just the current datetime
• start does not get reported by TF as changed (omitted)

Change my mind ☕️ 🤗

---

Versions

terraform {
  required_version = "~> 0.14.7"

  required_providers {
    pagerduty = {
      source = "pagerduty/pagerduty"
      version = "~> 1.9.6"
    }
  }
}

Backing evidence

I updated the state today at 13:50.
I run plan 4 minutes later without touching ANY code and this is the result:

# pagerduty_schedule.a
  ~ start = "2021-04-29T13:50:43+02:00" -> "2021-01-21T13:50:36+01:00"
# pagerduty_schedule.b
  ~ start = "2021-04-29T13:50:42+02:00" -> "2021-01-25T11:30:54+01:00"
# pagerduty_schedule.c
  ~ start = "2021-04-29T13:50:42+02:00" -> "2021-01-25T11:30:54+01:00"
# pagerduty_schedule.d
  ~ start = "2021-04-29T13:50:42+02:00" -> "2021-04-26T07:00:00+01:00"
# pagerduty_schedule.e
  ~ start = "2021-04-29T13:50:43+02:00" -> "2021-04-26T07:00:00+01:00"
# pagerduty_schedule.f
  ~ start = "2021-04-29T13:50:42+02:00" -> "2021-01-22T10:13:35+01:00"
# pagerduty_schedule.g
  ~ start = "2021-04-29T13:50:42+02:00" -> "2021-01-22T14:27:28+01:00"
# pagerduty_schedule.h
  ~ start = "2021-04-29T13:50:42+02:00" -> "2021-01-25T11:38:43+01:00"
# pagerduty_schedule.i
  ~ start = "2021-04-29T13:50:42+02:00" -> "2021-01-25T11:38:43+01:00"
# pagerduty_schedule.j
  ~ start = "2021-04-29T13:50:42+02:00" -> "2021-01-25T17:00:54+01:00"
# pagerduty_schedule.k
  ~ start = "2021-04-29T13:50:44+02:00" -> "2021-01-25T17:00:54+01:00"
# pagerduty_schedule.l
  ~ start = "2021-04-29T13:50:42+02:00" -> "2021-01-25T07:00:00+01:00"
# pagerduty_schedule.m
  ~ start = "2021-04-29T13:50:42+02:00" -> "2021-01-25T07:00:00+01:00"
# pagerduty_schedule.n
  ~ start = "2021-04-29T13:50:43+02:00" -> "2021-01-18T07:00:00+01:00"
# pagerduty_schedule.o
  ~ start = "2021-04-29T13:50:43+02:00" -> "2021-03-01T17:30:00+01:00"
# pagerduty_schedule.p
  ~ start = "2021-04-29T13:50:42+02:00" -> "2021-04-26T17:30:00+01:00"

Why? 😢
Am I doing it wrong?

[ghost]

Actually, on a second view I think it purely relates to UTC Daytime Adjustment 🧐

[stmcallister]

Hey Dominik! Thanks for the question and feedback. It looks like you're defining start times that are in the past. The PagerDuty API interprets start times in the past as the current of the call. One way I've heard of folks getting around seeing this diff you've described is by using the lifecycle field. It's a Terraform-specific field that allows you to ignore changes in particular fields on a resource.

For example, you would use it inside the pagerduty_schedule and set something like:

lifecycle {
    ignore_changes = [start]
}

[ghost]

@stmcallister Answer confirmed. Official syntax is:

resource "pagerduty_schedule" "x" {

  lifecycle {
    ignore_changes = [ layer["start"] ]
  }

  ...

  layer {
    ...
  }
}

[jashugan]

If you are using dynamic blocks, then ignore_changes attributes would need to be defined like so:

resource "pagerduty_schedule" "x" {
  for_each = var.schedules

  lifecycle {
    ignore_changes = [ layer[0].start, layer[1].start, layer[2].start, layer[3].start, layer[4].start ]
  }

  ...

  dynamic "layer" {
    for_each = lookup(each.value, "layers", {})
    content {
     ...
    }
  }
}

The downside to this is that you won't be able to schedule when layout changes take effect after the layer has been created. I haven't figured out a way around that problem.

[jashugan]

@stmcallister -- The workaround suggested here is problematic because my users can no longer schedule when they want layer changes to take effect. Do you have any ideas how to get around this problem?

[ghost]

@stmcallister I can confirm what @jashugan says. Since I added the ignore_changes the provider does no longer pickup any changes to the schedule (e.g. changing team members is just ignored).

[ghost]

I just observe that Terraform 1.0.0 handles it gracefully in fact ignoring it as

Note: Objects have changed outside of Terraform
...
# pagerduty_schedule.ai has been changed
  ~ resource "pagerduty_schedule" "..." {
        id          = "..."
        name        = "..."
        # (2 unchanged attributes hidden)

      ~ layer {
            id                           = "..."
            name                         = "primary"
          ~ start                        = "2021-01-22T14:47:10+01:00" -> "2021-07-06T11:45:09+02:00"
            # (3 unchanged attributes hidden)
        }
    }

Nice 🚀

[sgujavarthy]

Is there a solution identified for this besides the ignore_changes workaround?

If there are any properties in API call that are ignored and overridden by PagerDuty products, then forget about whether those are required/optional, those should not be part of the API input in the first place. This is really against the GitOps principles (this part of the API is not declarative)

[stmcallister]

Looks like we forgot to tag this issue when we made the fix for this. You should be able to fix this if you're using v1.9.8 or later of the PagerDuty provider.

I've connected with @sgujavarthy offline, so I'm going to close this issue. Please repost if you continue to have troubles.