azurerm_maintenance_configuration with scope of InGuestPatch and reboot Always Issue

[usvjosh]

Is there an existing issue for this?

• I have searched the existing issues

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 and review the contribution guide to help.

Terraform Version

1.5.6

AzureRM Provider Version

3.85.0

Affected Resource(s)/Data Source(s)

azurerm_maintenance_configuration

Terraform Configuration Files

resource "azurerm_maintenance_configuration" "maintenance_configuration_test_1100" {
  name                = "PatchServerOS-Test-Friday11"
  resource_group_name = azurerm_resource_group.resource_group_1.name
  location            = "centralus" //azurerm_resource_group.resource_group_1.location
  scope               = "InGuestPatch"
  tags                = local.azure_tags
  in_guest_user_patch_mode = "User"

    install_patches {
        reboot = "Always"

        linux {
            classifications_to_include    = [
                "Critical",
                "Security",
            ]
            package_names_mask_to_exclude = []
            package_names_mask_to_include = []
        }

        windows {
            classifications_to_include = [
                "Critical",
                "Security",
                "UpdateRollup",
                "Definition",
                "Updates",
            ]
            kb_numbers_to_exclude      = []
            kb_numbers_to_include      = []
        }
    }

    timeouts {}

    window {
        duration        = "02:00"
        recur_every     = local.test_window_recur_every
        start_date_time = "${local.test_window_start_date} 11:00"
        time_zone       = "Central Standard Time"
    }
}

Debug Output/Panic Output

# azurerm_maintenance_configuration.maintenance_configuration_test_1100 will be updated in-place
  ~ resource "azurerm_maintenance_configuration" "maintenance_configuration_test_1100" {
        id                       = "/subscriptions/[subid]/resourceGroups/sms-a2-core-patchmgmt-rg/providers/Microsoft.Maintenance/maintenanceConfigurations/PatchServerOS-Test-Friday11"
        name                     = "PatchServerOS-Test-Friday11"

      ~ install_patches {
          ~ reboot = "AlwaysReboot" -> "Always"

            # (2 unchanged blocks hidden)
        }

        # (2 unchanged blocks hidden)
    }

Plan: 1 to add, 30 to change, 0 to destroy.

Expected Behaviour

When setting the reboot property to a value of "Always" it should simply set it and never need apply this setting again (assuming it does not change in azure). On the azure side the value is "AlwaysReboot". There appears to be a difference between what the provider and the azure api are doing.

Actual Behaviour

The setting of "Always" is described as the proper way to set the value to "AlwaysReboot" but the API comes back with a different value on the next plan (after apply). So terraform wants to update the maint config each time.

Steps to Reproduce

Simply add a maint config with "Always", plan & apply it, then run a new plan, it'll detect a change and want to update the resource again and again.

Important Factoids

No response

References

https://learn.microsoft.com/en-us/azure/update-manager/manage-vms-programmatically?tabs=cli%2Crest

[harshavmb]

This seems to be an Azure API issue as AlwaysReboot is not listed on REST-API specs here.

If you don't intend to update reboot field, you could suppress the diff by using lifecycle meta argument like below..

lifecycle {
    ignore_changes = install_patches.0.reboot
}

Of course, this is just a workaround. The problem appears to be at Azure end. IMO it needs to be flagged with them rather with the azurerm provider.

However, I am open if Hashicorp has other thoughts on this.

[github-actions]

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.