Updating an `azurerm_automation_runbook` causes subsequent `terraform apply` to want to recreate the associated `azurerm_automation_job_schedule`

[mymasse]

Community Note

• Please vote on this issue by adding a 👍 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 0.13.3 and AzureRM Provider Version 2.24.0

Current providers:

- Using previously-installed hashicorp/time v0.5.0
- Using previously-installed hashicorp/tls v2.2.0
- Using previously-installed hashicorp/azurerm v2.24.0
- Using previously-installed hashicorp/azuread v0.11.0
- Using previously-installed hashicorp/random v2.3.0
- Using previously-installed hashicorp/null v2.1.2
- Using previously-installed hashicorp/external v1.2.0
- Using previously-installed hashicorp/local v1.4.0

Affected Resource(s)

• azurerm_automation_job_schedule
• azurerm_automation_runbook

Terraform Configuration Files

data "local_file" "sync_group_roles" {
  filename = "${path.module}/runbooks/sync-group-roles.ps1"
}

resource "azurerm_automation_runbook" "sync_group_roles" {
  name        = "Sync-Group-Roles"
  description = "Ensure members of Groups have the appropriate AD roles, since roles cannot be assigned to Groups."

  automation_account_name = azurerm_automation_account.account.name
  resource_group_name     = azurerm_resource_group.automation.name
  location                = azurerm_resource_group.automation.location

  runbook_type = "PowerShell"
  log_progress = false
  log_verbose  = false

  content = data.local_file.sync_group_roles.content

  tags = {
    "team" = local.automation_responsible_team
  }

  depends_on = [
    azurerm_automation_module.az_accounts,
    azurerm_automation_module.azuread,
    azurerm_automation_module.az_resources,
  ]
}

resource "azurerm_automation_schedule" "daily_ad_sync" {
  name = "Daily AD roles sync"

  automation_account_name = azurerm_automation_account.account.name
  resource_group_name     = azurerm_resource_group.automation.name

  frequency  = "Day"
  interval   = 1
  timezone   = local.timezone
  start_time = "${local.date_tomorrow}T07:00:00${data.external.timezone_offset.result["offset"]}"

  # Just making it explicit but from the documentation the start_time is only used on create.
  lifecycle {
    ignore_changes = [start_time]
  }
}

resource "azurerm_automation_job_schedule" "sync_group_roles" {
  automation_account_name = azurerm_automation_account.account.name
  resource_group_name     = azurerm_resource_group.automation.name

  schedule_name = azurerm_automation_schedule.daily_ad_sync.name
  runbook_name  = azurerm_automation_runbook.sync_group_roles.name
}

Expected Behavior

After an update on azurerm_automation_runbook no changes other than the runbook are done even on subsequent terraform apply

Actual Behavior

terraform apply after updating azurerm_automation_runbook

  # module.automation.azurerm_automation_job_schedule.sync_group_roles will be created
  + resource "azurerm_automation_job_schedule" "sync_group_roles" {
      + automation_account_name = "devops-automation"
      + id                      = (known after apply)
      + job_schedule_id         = (known after apply)
      + resource_group_name     = "AutomationRG"
      + runbook_name            = "Sync-Group-Roles"
      + schedule_name           = "Daily AD roles sync"
    }

Steps to Reproduce

1. Update configuration and/or content of azurerm_automation_runbook resource
2. terraform apply to update the runbook
3. terraform plan or terraform apply will now show that azurerm_automation_job_schedule needs be created.

References

This seems to be the exact same issue as #7130 which is supposed to be fixed in v2.21.0

[mybayern1974]

Hi @mymasse , by assuming this is duplicate with #7130 that has been resolved, could you please check whether you've also got unblocked? If yes would you mind if we close this issue? Or feel free to reopen if you believe you are still running into issues.

[mymasse]

Hi @mybayern1974, it is the same issue has #7130 but it seems it came back in 2.24.0. After every runbook updates the linked schedule still needs to be recreated. Can this be reopened

[braunsonm]

Experiencing this as well @mybayern1974 using the latest version of TF

[mymasse]

@mybayern1974 Can you reopen the ticket I don't have the option to.

[mybayern1974]

Reopen

[mymasse]

Still a problem with 2.49.0, is this going to be looked into?

[dpbustos]

Still a problem with v2.53

[thaiphv]

I'm on 2.56 and it still happens.

[922566]

still happens with 2.60

[w3bward]

I think the underlying issue is that updating a runbook breaks the associated job schedules. I've been banging my head against the wall because after deploying a change to a runbook, when I go to look at the associated job schedules in the portal, all but one are missing and the one that remains has had all of the assigned parameter values stripped out of it.

After applying the runbook change, a second subsequent apply will refresh the state, which detects that the job schedules are missing or changed, and recreates them.

In my case, I've been trying to figure out a workaround that doesn't require applying the configuration twice. Honestly, it would be fine if I could just force the job schedules to be recreated whenever a runbook is changed, but I haven't been able to figure out anything along those lines.

P.S. this is using Terraform 14.9 with AzureRM v. 2.66.0

[josem0287]

This is still happening, exactly what @w3bward described above. I'm using Terraform 1.0.4 and AzureRM v. 2.98.0

[WaitingForGuacamole]

Terraform 1.2.5 and AzureRM v3.15.0, still happening. Re-running plan and apply works for me, but now my workflow has to be run twice. Not ideal if I want to put this in a pipeline.

[wuxu92]

hi, @w3bward @mymasse could you please have a try with replace_triggered_by meta argument to see if meets your needs? more infomation reference to: https://github.com/hashicorp/terraform-provider-azurerm/issues/17970#issuecomment-1214602306

[Pesticles]

This is still a problem in v3.56.0 of the provider, nearly 3 years after it was reported. Can we pleeeeease get someone working on this?

I have a runbook with >50 schedules attached, generated in different stacks from the one the runbook is defined in (so I can't use the replace_triggered_by trick) so I currently have to re-run all 50+ stacks every time I make a change to the runbook. It's very annoying and time consuming.

[WaitingForGuacamole]

That workflow alone is worth a comment and an upvote.

[wuxu92]

This is still a problem in v3.56.0 of the provider, nearly 3 years after it was reported. Can we pleeeeease get someone working on this?

I have a runbook with >50 schedules attached, generated in different stacks from the one the runbook is defined in (so I can't use the replace_triggered_by trick) so I currently have to re-run all 50+ stacks every time I make a change to the runbook. It's very annoying and time consuming.

Hi @Pesticles, could you please give more details about can't use replace_triggered_by arguement? it should work in most of the time.

[Pesticles]

I have a runbook that updates a VMSS whose ID is provided as a parameter. This is defined in a Terraform stack, along with some other utility runbooks.

The job schedules which trigger this runbook are not defined in this stack, they're defined in the stacks which define the VMSS's, of which there are many. This way each time we create a new VMSS, it adds itself to the job schedules and gets updated, and when it gets destroyed, the schedule is removed.

It appears to me that, despite the Terraform plan showing a resource update (instead of a replacement) when the runbook code is changed, it is in fact doing a replacement. This is what causes the existing schedules to be lost.

If the plan matched the action, this would not be an issue. If the plan showed resource replacement, it would be expected that the schedules would be lost. If the resource update actually just updated the code, the schedules would not be lost.

My preference would be for a code change to simply update the code in the runbook without effecting any other features of the resource, including schedules. But if that's not possible for some reason then I think the behaviour of the resource should be changed to correctly indicate that a code change will cause a resource replacement.

[wuxu92]

@Pesticles that's really annoying there is gap between terraform plan and what terraform apply really does. One good news is I just found the cause of the issue and will submit a PR in the next few days(or weeks). Thank you for your detailed description and you patient waiting.

[S0meth1ng85]

@wuxu92 ,any news about this PR? It`s too inconvenient to run the same terraform plan/apply twice to regenerate job_schedule :\

[kacper-kucharski]

Hi,

Just wanted to mention that this issue is still occurring when can this be expected to be done?

Provider.tf

Terraform version 1.7.3 Azurerm version 3.94.0

Error: publishing the updated Runbook (Subscription: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" Resource Group Name: "xxxx" Automation Account Name: "xxx" Runbook Name: "Start_Azure_VMs"): performing Publish: unexpected status 404 with error: ResourceNotFound: The Resource 'Microsoft.Automation/automationAccounts/xxx/runbooks/Start_Azure_VMs' under resource group 'xxx' was not found. For more details please go to https://aka.ms/ARMResourceNotFoundFix

with module.automation_tasks.azurerm_automation_runbook.start_azure_vms[0], on ....\Shared-Modules\automation-tasks\automation-runbooks.tf line 36, in resource "azurerm_automation_runbook" "start_azure_vms": 36: resource "azurerm_automation_runbook" "start_azure_vms" {

I've noticed that it also sometimes is unable to create the runbook so it makes it as draft but then when trying to edit the powershell code in portal it give 404 not found.

What I did is after deleting a runbook I wait around 5 minutes and then try to create it which sometimes works but sometimes it still produces the same error.

I hope to hear what update are being regarding this as we would like this code to be able to run in a pipeline and don't want the code to be applied twice....

[dirghahermanta]

Still a problem on Terraform 1.7.5 and Azurerm 3.93.0. Do we have any expected timeframe for the fix?

[MiraKopecky82]

Hello,

still a problem on Terraform 1.7.5 and AzureRM 3.96.0.