Updating `azurerm_automation_runbook` removes many, if not all, `azurerm_automation_job_schedule` resources tied to that runbook.

[WaitingForGuacamole]

Is there an existing issue for this?

• [X] I have searched the existing issues

Community Note

• Please vote on this issue by adding a :thumbsup: reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

1.2.5

AzureRM Provider Version

3.15.1

Affected Resource(s)/Data Source(s)

azurerm_automation_runbook, azurerm_automation_job_schedule

Terraform Configuration Files

locals {
  copy_runbooks = ["Runbook1", "Runbook2"]
}

resource "azurerm_automation_runbook" "copy-runbooks" {
  for_each                = { for r in local.copy_runbooks : r => r }
  name                    = each.key
  location                = var.location
  resource_group_name     = "rg-${var.project_name}-${var.environment_name}-services"
  automation_account_name = "automation-${var.project_name}-${var.environment_name}"
  log_verbose             = "true"
  log_progress            = "true"
  description             = "Copy files between Azure Files in two storage accounts"
  runbook_type            = "PowerShell"

  publish_content_link {
    # uri must be specified, must be reachable, even when specifying content to override
    uri = "https://raw.githubusercontent.com/Azure-Samples/azure-files-samples/master/SyncBetweenTwoAzureFileSharesForDR/SyncBetweenTwoFileShares.ps1"
  }

  # override content with customized script
  content = file("${path.module}/runbooks/sync-shares.ps1")
}

# Force sleep before any schedule updates (in case there is some delay needed)
resource "time_sleep" "runbooks" {
  create_duration = "1m"

  depends_on = [azurerm_automation_runbook.copy-runbooks]
}

resource "azurerm_automation_job_schedule" "Runbook1-schedule" {
  depends_on = [
    time_sleep.runbooks
  ]
  for_each                = { for m in range(0, 60, 5) : substr("0${m}", -2, -1) => m }
  resource_group_name     = "rg-${var.project_name}-${var.environment_name}-services"
  automation_account_name = "automation-${var.project_name}-${var.environment_name}"
  schedule_name           = "hourly-${each.key}" # attach to shared schedule set
  runbook_name            = "Runbook1"  # attach unique copy of common runbook
  run_on                  = "hwg-${var.project_name}-${var.environment_name}"

  # set up runtime parameters for runbook
  parameters = {
    // ... parameters for Runbook1 here ...
  }
}

resource "azurerm_automation_job_schedule" "Runbook1-schedule" {
  depends_on = [
    time_sleep.runbooks
  ]
  for_each                = { for m in range(0, 60, 5) : substr("0${m}", -2, -1) => m }
  resource_group_name     = "rg-${var.project_name}-${var.environment_name}-services"
  automation_account_name = "automation-${var.project_name}-${var.environment_name}"
  schedule_name           = "hourly-${each.key}" # attach to shared schedule set
  runbook_name            = "Runbook2"  # attach unique copy of common runbook
  run_on                  = "hwg-${var.project_name}-${var.environment_name}"

  # set up runtime parameters for runbook
  parameters = {
    // ... parameters for Runbook2 here ...
  }
}

Debug Output/Panic Output

No errors, and plan/apply isn't revealing

Expected Behaviour

On an update to the script, the runbook should be updated. The association of the runbook to the shared schedules on the automation account ("hourly-00" thru "hourly-55") should be maintained.

Update script terraform plan Plan shows 2 resources to update terraform apply Runbook scripts are updated Schedule links associated with Runbook are maintained

Actual Behaviour

Update script terraform plan Plan shows 2 resources to update terraform apply Runbook scripts are updated All of the schedule links associated with the runbook are removed, except one (randomly) terraform plan Plan shows 24 resources to update (2 runbooks * 12 5-minute-interval schedule links) terraform apply Schedule links are restored

Steps to Reproduce

Update script terraform plan Plan shows 2 resources to update terraform apply Runbook scripts are updated All of the schedule links associated with the runbook are removed, except one (randomly)

Important Factoids

No response

References

https://github.com/hashicorp/terraform-provider-azurerm/issues/7130 https://github.com/hashicorp/terraform-provider-azurerm/issues/8634

[wuxu92]

hi @WaitingForGuacamole it's a by-design feature of azurerm that needs two terraform apply to recreate the job_schedule link for terraform's limitation. you can use the job_schedule property of azurerm_automation_runbook resource to manage the job_schedules, but i found there is a bug(which is the source cause of randomly one link reserved) in the code which causes the job_schdule property doesn't work well, and i am trying to fix it now.

[wuxu92]

hi @WaitingForGuacamole there is a replace_triggered_by mete argument from terraform1.2 which can use to auto replace the job_schedule_link

here is the reference: https://www.terraform.io/language/meta-arguments/lifecycle#replace_triggered_by

an example config which should meet your requirement in my local test:

resource "azurerm_automation_job_schedule" "Runbook1-schedule" {
  depends_on = [
    time_sleep.runbooks
  ]
  lifecycle {
    replace_triggered_by = [azurerm_automation_runbook.copy-runbooks["Runbook1"]]
  }
  for_each                = { for m in range(0, 60, 30) : substr("0${m}", -2, -1) => m }
  resource_group_name     = azurerm_resource_group.test.name
  xxx
}

[WaitingForGuacamole]

@wuxu92 I'm on PTO this week, but this workaround looks extremely promising - I'll give it a try and get back to you roughly a week from now. Thanks very much!

[Amier3]

Thanks Xu for the workaround! Going to go ahead and close this issue now.

[github-actions[bot]]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.