Next Steps For AzureRM

[stack72]

This is the roll up issue to track the next pieces of work requires for AzureRM:

• Update AzureRM SDK Version - - Fixed by deps: Upgrade Azure SDK for Go #6976
• azurerm_virtual_machine shows availability_set_id shows continual changes (possibly due to casing) - Azure RM Availability Set #6331 / azurerm availability set case mismatch #6433 - Fixed by Normalizes availability_set_id to lowercase to avoid spurious diffs #6768
• azurerm_virtual_machine cannot update vm_size - azurerm can not adjust vm-size after deploy #6517 - Fixed by provider/azurerm: Update azurerm_virtual_machine failed on adminPassword #6528
• Potential issue creating virtual networks / subnets - error creating vnet/subnet azurerm resource in 0.6.14 #5827 / azurerm 0.6.14 400 Bad Request creating nic  #5829 Closed as cannot replicate
• Investigate why vhd cannot be used as a reference source image on azurerm_virtual_machine - azurerm - unable to use a vhd as a reference source image #6494 Fixed by [azurerm] Add os_type and image_uri in azurerm_virtual_machine #6553
• error creating vm from existing vhd - osType not supplied - azurerm - error creating vm from existing vhd - osType not supplied #6372 Fixed by [azurerm] Add os_type and image_uri in azurerm_virtual_machine #6553
• Error while assigning a SSH key to a VM with azurerm - Error while assigning a SSH key to a VM with azurerm #6212 / azurerm_virtual_machine broken in 0.6.14 #5793 Fixed by provider/azurerm: Fix an issue with azurerm_virtual_machine ssh_keys #6541
• Error creating vm with data disk - Error creating vm with data disk  #6120 / AzureRM Data Disk #6150 Fixed by provider/azurerm: Error creating azurerm_virtual_machine data_disk #6543

[clintonm9]

What about the ssh key issue #6212 and data disk issue #6120? Can we add those to the list?

[stack72]

@clintonm9 you caught me in the process of the issue creation :)

[clintonm9]

ha, np.

How about this one ;)
azurerm can not use count attribute correctly #6516

[stack72]

@clintonm9 looks like the ability to update a virtual machine vm_Size will be part of 0.6.16 - just found the error and am waiting for the tests to run now

[stack72]

I have been able to recreate the casing of availability_set_id issues (#6331). This has been reported to the Azure-sdk-for-go team (Azure/azure-sdk-for-go#324) - we need to wait for them to tell us why this is the case

[Felivel]

About the casing of availability_set_id issue (#6331), I am able to work around the problem by setting the azurerm_availability_set.name in all caps.

E.g:

resource "azurerm_availability_set" "test_availability_set" {
    name = "${upper(var.deployment)}-TEST-AVAILABILITY-SET"
    location = "${var.azure_location}"
    resource_group_name = "${azurerm_resource_group.core_resource_group.name}"
}

Apparently Azure is upper casing the names.
Maybe we can upper case it automatically.

[majormoses]

@Felivel that's strange unless something has changed in the last little bit it should allow lowercase... I can try testing when I have a minute... this is what I had defined and it worked for me:

resource "azurerm_availability_set" "dev-azure-es-app-master" {
    name = "dev-azure-es-app-master"
    location = "West US"
    resource_group_name = "${azurerm_resource_group.dev-azure.name}"

    tags {
        environment = "dev-azure"
    }
}

if this is now true then I would not want it to auto uppercase but rather add validation in terraform to warn user. @stack72 any thoughts?

[majormoses]

@Felivel sounds like a red herring as I am able to create with lowercase just fine

My config:

resource "azurerm_availability_set" "dev-azure-es-app-master-test" {
    name = "dev-azure-es-app-master-test"
    location = "West US"
    resource_group_name = "${azurerm_resource_group.dev-azure.name}"

    tags {
        environment = "dev-azure"
    }
}

My plan:

+ azurerm_availability_set.dev-azure-es-app-master-test
    location:                     "" => "westus"
    name:                         "" => "dev-azure-es-app-master-test"
    platform_fault_domain_count:  "" => "3"
    platform_update_domain_count: "" => "5"
    resource_group_name:          "" => "dev-azure"
    tags.#:                       "" => "1"
    tags.environment:             "" => "dev-azure"

Applied successfully:

azurerm_availability_set.dev-azure-es-app-master-test: Creating...
  location:                     "" => "westus"
  name:                         "" => "dev-azure-es-app-master-test"
  platform_fault_domain_count:  "" => "3"
  platform_update_domain_count: "" => "5"
  resource_group_name:          "" => "dev-azure"
  tags.#:                       "" => "1"
  tags.environment:             "" => "dev-azure"
azurerm_availability_set.dev-azure-es-app-master-test: Creation complete

Apply complete! Resources: 1 added, 0 changed

[clintonm9]

@majormoses The issue is when you update the resource after it is deployed. It will keep thinking there's a difference in the lower case version.

[majormoses]

@clintonm9 can you be more specific on what you are updating? I just updated it with a simple tag.

plan:

~ azurerm_availability_set.dev-azure-es-app-master-test
    tags.#:    "1" => "2"
    tags.test: "" => "true"

aplly:

$ tfa
azurerm_availability_set.dev-azure-es-app-master-test: Modifying...
  tags.#:    "1" => "2"
  tags.test: "" => "true"
azurerm_availability_set.dev-azure-es-app-master-test: Modifications complete

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

modifying an existing tag works as well...

[clintonm9]

@majormoses What version are you using?

[majormoses]

@clintonm9 I tested with .14 and .15

[majormoses]

I brought up a new machine in a new availability set to test and am unable to reproduce so its possible that they fixed it upstream in the go sdk.

[clintonm9]

@majormoses The issue is not when you update the availability set. It is when you apply that to a azurerm_virtual_machine. After applying try running terraform plan. You will see the casting is wrong and it is trying to update the VM (which it will fail if you try)

See this config example:
https://gist.github.com/clintonm9/218c139385acdd930291cdc1fd569f1f

@Felivel the all caps works for me as well, how ugly looking :)

[Felivel]

@majormoses as @clintonm9 mentioned, the problem is when you try to re-apply.

I noticed that in some places of the azure portal you can see the availability set name in all caps.
We have two fields here: id (always get created in caps) and the name (can be lowercase).

Here is an example from the AzureRM API:

...
{
  "id": "/subscriptions/*/resourceGroups/*/providers/Microsoft.Compute/availabilitySets/TEST-AVAILABILITY-SET",
  "name": "test-availability-set",
  "type": "Microsoft.Compute/availabilitySets",
  "location": "eastus"
}
...

I just tried to reproduce the problem just now and it seems to be fixed. The AzureRM API returned the lower case name and id as expected.

[johngossman]

Hi all. In general Azure ids have to be interpreted case insensitively. Several of the backends normalize and we didn't enforce this (maintaining the case as originally submitted) strongly in the common frontend. I can only cite Postel's Law and Sir Tim's comments about URLs being case insensitive and apologize for the inconvenience.

[ghost]

I can confirm that #6494 has been fixed in #6553

My observations so far:

The source and destination vhd uri must be within the same storage account, but that storage account can be in a different resource group to the VM, providing both resource groups are in the same subscription.

[stack72]

HI all

This initial pass of what was required for AzureRM progress for 0.7 has been taken care of. There will be another round of changes soon

Paul

[imduffy15]

@stack72 Do you have an example of how to bring up a VM by cloning a VHD that is stored in blob storage? I keep getting issues using:

resource "azurerm_virtual_machine" "test" {
    name = "imduffy-vm"
    location = "${var.location}"
    resource_group_name = "${azurerm_resource_group.production.name}"
    network_interface_ids = ["${azurerm_network_interface.networkinterface.id}"]
    vm_size = "Standard_A0"

    storage_os_disk {
        name = "myvirtualmachinedisk"
        vhd_uri = "https://newvhd1466111068587.blob.core.windows.net/vm-images/CentOS6-Hardened.vhd"
        create_option = "fromImage"
        os_type = "linux"
    }

    os_profile {
        computer_name = "example"
        admin_username = "cloud-user"
        admin_password = "Password12345!"
    }
}

{
    "error": {
        "code": "InvalidParameter",
        "target": "osDisk",
        "message": "Cannot specify user image overrides for a disk already defined in the specified image reference."
    }
}

[ghost]

@imduffy15 @stack72

This is what I use:

storage_os_disk {
        name = "XXXXX"
        #Source VHD as reference
        image_uri = "https://XXX.vhd"
        #Destination vhd to create
        vhd_uri = "https://YYY.vhd"
        create_option = "fromImage"
        os_type = "linux"
    }

[samdunne]

@stack72 is setting up Alerts via Terraform on the road map?

[stack72]

Hi @samdunne

As I don't work for HC, I have access to no official roadmap for AzureRM. I think the best thing to do, is open an issue and request it :)

The team (or an OSS contributor) can triage the work involved

Hope this helps

P.

[ghost]

can somebody help me on how to create Azure VM from image of shared image gallery

[ghost]

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.