Terraform-provider-azurerm: Feature Request: DevTest Lab Schedules support for ComputeVmShutdownTask task type

[mikebranstein]

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

Description

As of the 1.33.0 release of DevTest Labs Schedules, a schedule can only be applied to a DevTest Lab via the lab_name property. Azure also uses these schedules to perform automated VM shutdowns for VMs outside of DevTest Labs.

For example, the ARM JSON for such a shutdown schedule is:

{
  "type": "microsoft.devtestlab/schedules",
  "apiVersion": "2016-05-15",
  "name": "<dev-test-lab-schedule-name>",
  "location": "<location>",
  "properties": {
    "status": "Enabled",
    "taskType": "ComputeVmShutdownTask",
    "dailyRecurrence": {
      "time": "1900"
    },
    "timeZoneId": "Eastern Standard Time",
    "notificationSettings": {
      "status": "Disabled",
      "timeInMinutes": 30
    },
    "targetResourceId": "<vm-external-id>",
    "provisioningState": "Succeeded",
    "uniqueIdentifier": "<resource-uuid>"
  }
}

As you can see, the targetResourceId points to a VM's external id instead of a DevTest Lab. The task type is also different from what is supported by the v1.33.0 resource currently.

The external id is formatted as: /subscriptions/<subscription_id>/resourceGroups/<resource-group-name>/providers/Microsoft.Compute/virtualMachines/<virtual-machine-name>

New or Affected Resource(s)

• azurerm_dev_test_schedule

Potential Terraform Configuration

This could mean lab_name becomes an optional parameter, and require the name or id of the virtual machine to be optional. The ComputeVmShutdownTask would need added as a valid task type.

References

• #2334
• https://azure.microsoft.com/en-us/blog/announcing-auto-shutdown-for-vms-using-azure-resource-manager/

[katbyte]

This seems like a duplicate of #2334, which was closed by #3554

[mikebranstein]

This should not be closed. v1.33.0 did not address the issue. See the above description for the details on why 1.33.0 does not provide a complete solution.

[mikebranstein]

@katbyte Please reconsider opening this, as v1.33.0 did not address the issue.

As of the 1.33.0 release of DevTest Labs Schedules, a schedule can only be applied to a DevTest Lab via the lab_name property. Azure also uses these schedules to perform automated VM shutdowns for VMs outside of DevTest Labs.

For example, the ARM JSON for such a shutdown schedule is:

{
  "type": "microsoft.devtestlab/schedules",
  "apiVersion": "2016-05-15",
  "name": "<dev-test-lab-schedule-name>",
  "location": "<location>",
  "properties": {
    "status": "Enabled",
    "taskType": "ComputeVmShutdownTask",
    "dailyRecurrence": {
      "time": "1900"
    },
    "timeZoneId": "Eastern Standard Time",
    "notificationSettings": {
      "status": "Disabled",
      "timeInMinutes": 30
    },
    "targetResourceId": "<vm-external-id>",
    "provisioningState": "Succeeded",
    "uniqueIdentifier": "<resource-uuid>"
  }
}

As you can see, the targetResourceId points to a VM's external id instead of a DevTest Lab. The task type is also different from what is supported by the v1.33.0 resource currently.

The external id is formatted as: /subscriptions/<subscription_id>/resourceGroups/<resource-group-name>/providers/Microsoft.Compute/virtualMachines/<virtual-machine-name>

[hashibot[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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!