Specifying a date in the future

Terraform
1

Hi Rock-stars, I have a question/situation: I am trying to setup an Azure Automation Schedule to run at 8AM the following day; however, I cannot seem to find any examples or abilities to do this for succession deployments. Meaning, I can set it up like this:

start_time = “2020-05-02T13:00:00Z”

But if we run a future deployment it will fail since it is in the past. I tried using the following code:

start_time = “${split(“T”, timestamp())[0]}T13:00:00Z”

However, that will only work if you execute the deployment sometime between midnight and 7:55AM the next day.

I’ve tried using the timeadd but that only allows time not days (again, I need this to run at the next morning at 8AM regardless of what time the deployment runs).

Below is the entire block I’m working with for reference.

resource “azurerm_automation_schedule” “resumedw” {
name = “${azurerm_automation_runbook.resumedw.name}-Mon-Fri-8AM”
resource_group_name = azurerm_resource_group.shared.name
automation_account_name = azurerm_automation_account.shared.name
frequency = “Week”
interval = 1
start_time = “2020-05-02T13:00:00Z”
timezone = “Central Standard Time”
description = “Resume Data Warehouses at 8AM Monday-Friday”
week_days = [“Monday”, “Tuesday”, “Wednesday”, “Thursday”, “Friday”]

lifecycle {
ignore_changes = [
start_time
]
}

Certainly appreciate any assisistance!

2

Hi @bingerk!

This seems like one of those situations where it can be helpful for a provider to offer a little extra abstraction on top of what the underlying API offers to work better within Terraform’s model. Specifically, to take as an argument a rule for deciding the start_time rather than a literal start_time, which the resource logic could then manage to ensure that it only changes if something else has changed to warrant it. (Assuming I understood correctly the point of this.)

It’s a tricky thing to solve with the Terraform language alone because the Terraform language is designed primarily for describing “stable” values that only vary when their explicit inputs change. Functions like timestamp that bring in external state are there for pragmatic reasons but don’t tend to compose well with other language features.

The best idea I can think of for this is to do some conditional logic based on the current wallclock time so that it does a different calculation depending on whether the current wallclock time is before or after the scheduled run time. Something like this, perhaps:

locals {
  current_time           = timestamp()
  start_wallclock_time   = "7.55"
  current_wallclock_time = formatdate("h.mm", local.current_time)
  schedule_tomorrow      = (local.current_wallclock_time >= local.start_wallclock_time)
  today                  = formatdate("YYYY-MM-DD", local.current_time)
  tomorrow               = formatdate("YYYY-MM-DD", timeadd(local.current_time, "24h"))
  start_time             = "${local.schedule_tomorrow ? local.tomorrow : local.today}T07:55:00Z"
}

With the above, local.start_time should then be a value suitable for the start_time argument you want to populate. I tested this after 07:55 UTC, so I’ve only been able to test the “tomorrow” behavior myself here, but hopefully they both work!

1 Like
3

@apparentlymart Thank you so much - I’ll give that a shot and let you know the results. Really appreciate it.

  • Karl
4

That worked beautifully, thanks again!

1 Like
5

just to add my thanks for that!

6

just want to say thank you for this too, very helpful!!

One thing that i noticed though however, if you have the below configured, it for some reason creates it an hour later (06:45)
start_time = “${local.schedule_tomorrow ? local.tomorrow : local.today}T05:45:00Z”