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

virtual_machine: Setting ultra_ssd_enabled from implicit default to explicit default value false does not work #8606

Closed
NilsBusche opened this issue Sep 24, 2020 · 4 comments · Fixed by #24274

Comments

@NilsBusche
Copy link
Contributor

NilsBusche commented Sep 24, 2020

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 (and AzureRM Provider) Version

Terraform v0.12.29 (also tried with Terraform v0.13.3)
terraform-provider-azurerm_v2.28.0_x5

Affected Resource(s)

  • azurerm_linux_virtual_machine
  • azurerm_windows_virtual_machine

Terraform Configuration Files

resource "azurerm_linux_virtual_machine" "instance" {
  name                  = var.hostname
  location              = data.azurerm_resource_group.rg_vm.location
  resource_group_name   = data.azurerm_resource_group.rg_vm.name
  network_interface_ids = [azurerm_network_interface.nic_0.id]
  size                  = var.flavor
  computer_name         = var.hostname
  admin_username        = var.os_username

  source_image_reference {
    publisher = var.image_publisher
    offer     = var.image_offer
    sku       = var.image_sku
    version   = var.image_version
  }

  os_disk {
    name                 = "${var.hostname}_volume_0"
    caching              = "ReadWrite"
    storage_account_type = "Premium_LRS"
    disk_size_gb         = var.bootdisksize
  }

  admin_ssh_key {
    public_key = file(var.ssh_key_path)
    username   = var.os_username
  }

  boot_diagnostics {
    storage_account_uri = var.storage_uri
  }
}

Expected Behavior

If you add additional_capabilities block with ultra_ssd_enabled = false to the above shown HCL, Terraform should do nothing. In the Azure API false is the default, so if you did not specify the attribute before it is the same as setting it now to false.

Actual Behavior

Terraform thinks there is a change to additional_capabilities and ultra_ssd_enabled and tries updating:

      + additional_capabilities {
          + ultra_ssd_enabled = false
        }

But it fails with following error message:
OperationNotAllowed" Message="'additionalCapabilities.ultraSSDEnabled' can be updated only when VM is in deallocated state.
In normal scenarios (Updating ultra_ssd_enabled from no value to true or from true to false) Terraform recognizes that a deallocation is needed and deallocates the VM.

I think the failure is caused because Azure API does not return the default value false if you did not explicitly specified it. So Terraform thinks there is change: "" -> false

Steps to Reproduce

  1. terraform apply the above described HCL
  2. Add following block:
  additional_capabilities {
    ultra_ssd_enabled = false
  }
  1. terraform plan/terraform apply

Important Factoids

Could be similar issue as for license_type in azurerm_windows_virtual_machine. There it was solved using DiffSuppressFunc (see #8542), but I did not get it working for this issue.

@NilsBusche
Copy link
Contributor Author

I tried adding a DiffSuppressFunc for ultra_ssd_enabled:

--- a/azurerm/internal/services/compute/virtual_machine.go
+++ b/azurerm/internal/services/compute/virtual_machine.go
@@ -29,6 +29,13 @@ func virtualMachineAdditionalCapabilitiesSchema() *schema.Schema {
                                        Type:     schema.TypeBool,
                                        Optional: true,
                                        Default:  false,
+                                       DiffSuppressFunc: func(_, old, new string, _ *schema.ResourceData) bool {
+                                               if old == "false" && new == "" || old == "" && new == "false" {
+                                                       return true
+                                               }
+
+                                               return false
+                                       },
                                },
                        },
                },

This does not work because it only applies to the ultra_ssd_enabled attribute within the block additional_capabilities. For the attribute itself the diff is suppressed as desired. But the block itself still will be added. So terraform plan would look like this:

 + additional_capabilities {}

And this ends in a Terraform crash.

Our use case for adding ultra_ssd_enabled = false to the configuration is when importing existing VMs. We have one default template for all VMs (self created and imported) where this setting is defined. So for self created VMs there is no problem, because we already have set ultra_ssd_enabled = false at creation. But for imported VMs the Azure API returns additional_capabilities as empty block and this leads to the described problem.

Is there a way to tell Terraform that it should ignore empty blocks? Or has anyone an idea how to get this fixed?

@jasonwbarnett
Copy link

In addition to the problem described, if you set it to null, it still takes action as well, when it shouldn't. For example, if someone creates a module with an input variable for setting

# my_module/main.tf

additional_capabilities {
  ultra_ssd_enabled = var.ultra_ssd_enabled
}
# my_module/variables.tf

variable "ultra_ssd_enabled" {
  description = "Whether or not you want ultra ssd enabled."
  type        = bool
  default     = null
}

If it isn't specified I would expect it to not be added to the request.

@rcskosir
Copy link
Contributor

Thanks for opening this issue. This was a problem in the 2.x version of the provider which is no longer actively maintained.
If this is still an issue with the 3.x version of the provider please do let us know by opening a new issue, thanks!

Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 28, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
5 participants