Azurerm_managed_disk - argument depreciation warning

Terraform Providers Azure
1

Hello, first post here, nice to meet you all!

Lately, we finally began migrating to AzureRM 3.x (we were sitting on 2.99 for a bit too long). The migration itself went fine, docs were quite helpful here. After the migration, we started to deal with any depreciation warnings - frist resources, then arguments.

This is where we encountered small problem - we got bunch of warnings related to azurerm_managed_disk about argument being deprecated:

Warning: Argument is deprecated

with module.my_vm.azurerm_managed_disk.data_disk["my_disk_1"],
on ..\_modules\virtual_machine\main.tf line 115, in resource "azurerm_managed_disk" "data_disk":
  115: resource "azurerm_managed_disk" "data_disk" {

Deprecated, Azure Disk Encryption is now configured directly by `disk_encryption_key` and `key_encryption_key`. To disable Azure Disk Encryption, please remove `encryption_settings` block. To enabled, specify a `encryption_settings` block`

At first glance, it’s not really clear which argument is deprecated, but by running some comparison between latest and v2.99 docs, we assume it’s enabled argument inside encryption_settings block.

The problem is - we’re not using encryption_settings on our azurerm_managed_disks - we deal with ADE by using vm extension:

resource "azurerm_managed_disk" "data_disk" {
  # other arguments, encryption_settings is not set
  lifecycle {
    ignore_changes = [
      encryption_settings
    ]
  }
}
resource "azurerm_virtual_machine_extension" "ade_extension" {
  # other arguments
 
  settings = <<SETTINGS
    {
        # extension specific settings
    }
SETTINGS

  depends_on = [
    some_other_resources
  ]
}

We investigated our state with terraform state pull and enabled flag is not here.

Could the root of our issue be that we’re ignoring encryption_settings on the disks, due to fact that we setup ADE by azurerm_virtual_machine_extension? If yes, can we do anything about it? At the end of the day, they’re just warnings, but we don’t want to just sit there and ignore them completely. :slight_smile: