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

VM Scale Set deployments on API 2017-03-30 fail due to ambiguous ssh keys representation #799

Closed
justenwalker opened this issue Feb 5, 2018 · 1 comment · Fixed by #797
Labels
Milestone

Comments

@justenwalker
Copy link
Contributor

Terraform Version

Terraform version: 0.11.3 3802b14260603f90c7a1faf55994dcc8933e2069

Affected Resource(s)

  • azurerm_virtual_machine_scale_set

Terraform Configuration Files

# terraform import "azurerm_virtual_machine_scale_set.testprovmss" "/subscriptions/SUBSCRIPTION-ID/resourceGroups/test-vmss/providers/Microsoft.Compute/virtualMachineScaleSets/testprovmss"
resource "azurerm_virtual_machine_scale_set" "testprovmss" {
  name                = "testprovmss"
  location            = "${azurerm_resource_group.test-vmss.location}"
  resource_group_name = "${azurerm_resource_group.test-vmss.name}"

  tags {
    superhero = "guardians"
  }

  upgrade_policy_mode = "Manual"
  single_placement_group = true
  overprovision = true

  sku {
    name     = "Standard_A0"
    tier     = "Standard"
    capacity = 0
  }
  os_profile {
    computer_name_prefix = "testprovm"
    admin_username       = "${local.admin_account["username"]}"
    admin_password       = "${local.admin_account["password"]}"
  }
  # Linux
  os_profile_linux_config {
    disable_password_authentication = false
  }
  storage_profile_image_reference {
    publisher = "Canonical"
    offer     = "UbuntuServer"
    sku       = "16.04-LTS"
    version   = "latest"
  }
  # OS Disk
  storage_profile_os_disk {
    caching           = "ReadWrite"
    create_option     = "FromImage"
    managed_disk_type = "Standard_LRS"
  }
  network_profile {
    name    = "testprovmssNic"
    primary = true
    ip_configuration {
      name        = "testprovmssIpConfig"
      subnet_id   = "/subscriptions/SUBSCRIPTION-ID/resourceGroups/test-vmss/providers/Microsoft.Network/virtualNetworks/VNET/subnets/SUBNET"
      load_balancer_backend_address_pool_ids = ["/subscriptions/SUBSCRIPTION-ID/resourceGroups/test-vmss/providers/Microsoft.Network/loadBalancers/LOADBALANCER/backendAddressPools/bepool"]
      load_balancer_inbound_nat_rules_ids = ["/subscriptions/SUBSCRIPTION-ID/resourceGroups/test-vmss/providers/Microsoft.Network/loadBalancers/LOADBALANCER/inboundNatPools/natpool"]
    }
  }
}

Expected Behavior

Deployment of VM scale set should succeed

Actual Behavior

Got unexpected error

compute.VirtualMachineScaleSetsClient#CreateOrUpdate: Failure sending request: StatusCode=409 -- Original Error: failed request: autorest/azure: Service returned an error. Status=<nil> Code="PropertyChangeNotAllowed" Message="Changing property 'linuxConfiguration.ssh.publicKeys' is not allowed."

Steps to Reproduce

  1. Create test-vmss through the portal. (This created a resource group with a vnet, public ip, load balancer, and the vm scale set.)
  2. Import this resource into terraform by creating a resource file and importing state with terraform import.
  3. Run terraform apply

Important Factoids

  • The key difference is that, when the portal creates VMSS resources, I creates them with a null ssh property.
    When terraform applies its changes, it tries to set this value to an empty public keys list.
72c74,76
<         "ssh": null
---
>         "ssh": {
>           "publicKeys": []
>         }

These two settings mean the same thing, however; the azure api does not allow you to change the null value once it has been deployed, and since terraform always tries to post the ssh.publicKeys array, it will never succeed until this resource is re-created via terraform.

  • This is confirmed with Microsoft to be issue with the version of the compute api that is built into this provider. 2017-03-30 fails because it does not allow modifications to the ssh object. 2017-12-01 succeeds because it does allow this modification.

References

@ghost
Copy link

ghost commented Mar 31, 2020

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!

@ghost ghost locked and limited conversation to collaborators Mar 31, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants