Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for patchmode "customer managed schedules" #27153

Open
1 task done
allthetrouts opened this issue Aug 22, 2024 · 5 comments
Open
1 task done

Support for patchmode "customer managed schedules" #27153

allthetrouts opened this issue Aug 22, 2024 · 5 comments

Comments

@allthetrouts
Copy link

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 comments along the lines of "+1", "me too" or "any updates", 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.

Description

Please add support for "Customer Managed Schedules" for both azurerm_windows and linux virtual machine resources. With Azure Update Manager now we need to deploy vm's with patchmode set to "Customer Managed Schedules" and no longer "ImageDefault" and "AutomaticByPlatform"

New or Affected Resource(s)/Data Source(s)

azurerm_linux_virtual_machine; azurerm_windows_virtual_machine

Potential Terraform Configuration

patch_mode                        = "Customer Managed Schedules"

References

No response

@harshavmb
Copy link
Contributor

Hi @allthetrouts ,

I don't find support for Customer Managed Schedules neither in hashicorp-2024-07-01 nor azure-2024-07-01.

If it's not part of restapi yet, it can't be supported via azurerm provider. Can you paste link to the docs supporting Customer Managed Schedules?

@emerconn
Copy link

emerconn commented Aug 29, 2024

Hello @harshavmb

I am also running into this issue. We have a Maintenance Configuration definition to apply patching schedules based on tags. So after Terraform deploys the VM and assigns the correct tag, this Maintenance Configuration takes over for patching.

This is what my AUM looks like.

image

I took manual action on the first 4 VMs, using the directions in the following screenshot. The VMs with [⚠️Fix] next to them have not been touched since Terraform created them. Here is the instructions from the Fix hyperlink:

image

This is the click here hyperlink in the screenshot: https://learn.microsoft.com/en-us/azure/update-manager/prerequsite-for-schedule-patching?tabs=new-prereq-portal%2Cauto-portal

@emerconn
Copy link

emerconn commented Aug 29, 2024

bypassPlatformSafetyChecksOnUserSchedule does exist in azure-2024-07-01, but does not in hashicorp-2024-07-01.

@emerconn
Copy link

emerconn commented Sep 4, 2024

I ended up creating an Azure policy to set bypassPlatformSafetyChecksOnUserSchedule to true for virtual machines using a specific tag, which is used by our Azure Maintenance Configuration.

I noticed that upon running Terraform again on the created resource after this policy is applied, Terraform wants to set bypassPlatformSafetyChecksOnUserSchedule back to false, even though there is no parameter for this listed in the documentation.

  # azurerm_windows_virtual_machine.sql_server["PROD-<redacted>"] will be updated in-place
  ~ resource "azurerm_windows_virtual_machine" "sql_server" {
      ~ bypass_platform_safety_checks_on_user_schedule_enabled = true -> false

@emerconn
Copy link

emerconn commented Sep 4, 2024

I'm not sure why this is working, but I added bypass_platform_safety_checks_on_user_schedule_enabled to the lifecycle ignore list which fixed the problem. I took it one step further and added it as a parameter to the azurerm_windows_virtual_machine resource, which also works.

So it looks like this is functional, it's just not documented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants