Azurerm Virtual Machine casing for availability_set_id between Create and Read

[stack72]

I have the following request being used to create a VM:

{
    "name": "test",
    "location": "West US",
    "properties": {
        "hardwareProfile": {
            "vmSize": "Standard_A0"
        },
        "storageProfile": {
            "imageReference": {
                "publisher": "Canonical",
                "offer": "UbuntuServer",
                "sku": "14.04.2-LTS",
                "version": "latest"
            },
            "osDisk": {
                "name": "myosdisk1",
                "vhd": {
                    "uri": "https://testeaed3as9a7ca.blob.core.windows.net/test/myosdisk1.vhd"
                },
                "caching": "ReadWrite",
                "createOption": "FromImage"
            }
        },
        "osProfile": {
            "computerName": "hostname1",
            "adminUsername": "adminUSer",
            "adminPassword": "Password1234",
            "linuxConfiguration": {
                "disablePasswordAuthentication": false,
                "ssh": {
                    "publicKeys": []
                }
            }
        },
        "networkProfile": {
            "networkInterfaces": [{
                "id": "/subscriptions/34ca515c-4629-458e-bf7c-738d77e0d0ea/resourceGroups/testavilset/providers/Microsoft.Network/networkInterfaces/test"
            }]
        },
        "availabilitySet": {
            "id": "/subscriptions/34ca515c-4629-458e-bf7c-738d77e0d0ea/resourceGroups/testavilset/providers/Microsoft.Compute/availabilitySets/test"
        }
    }
}

Notice the availabilitySet: /subscriptions/34ca515c-4629-458e-bf7c-738d77e0d0ea/resourceGroups/testavilset/providers/Microsoft.Compute/availabilitySets/test

When reading back the VM information, I get the following response:

{
    "properties": {
        "vmId": "ed6b9413-7c38-465c-a294-ce135b24bec7",
        "availabilitySet": {
            "id": "/subscriptions/34ca515c-4629-458e-bf7c-738d77e0d0ea/resourceGroups/testavilset/providers/Microsoft.Compute/availabilitySets/TEST"
        },
        "hardwareProfile": {
            "vmSize": "Standard_A0"
        },
        "storageProfile": {
            "imageReference": {
                "publisher": "Canonical",
                "offer": "UbuntuServer",
                "sku": "14.04.2-LTS",
                "version": "latest"
            },
            "osDisk": {
                "osType": "Linux",
                "name": "myosdisk1",
                "createOption": "FromImage",
                "vhd": {
                    "uri": "https://testeaed3as9a7ca.blob.core.windows.net/test/myosdisk1.vhd"
                },
                "caching": "ReadWrite"
            },
            "dataDisks": []
        },
        "osProfile": {
            "computerName": "hostname1",
            "adminUsername": "adminUSer",
            "linuxConfiguration": {
                "disablePasswordAuthentication": false,
                "ssh": {
                    "publicKeys": []
                }
            },
            "secrets": []
        },
        "networkProfile": {
            "networkInterfaces": [{
                "id": "/subscriptions/34ca515c-4629-458e-bf7c-738d77e0d0ea/resourceGroups/testavilset/providers/Microsoft.Network/networkInterfaces/test"
            }]
        },
        "provisioningState": "Creating"
    },
    "id": "/subscriptions/34ca515c-4629-458e-bf7c-738d77e0d0ea/resourceGroups/testavilset/providers/Microsoft.Compute/virtualMachines/test",
    "name": "test",
    "type": "Microsoft.Compute/virtualMachines",
    "location": "westus"
}

Notice the availabilitySet here: /subscriptions/34ca515c-4629-458e-bf7c-738d77e0d0ea/resourceGroups/testavilset/providers/Microsoft.Compute/availabilitySets/TEST

The casing on the name of the availabilitySet has changed from test to TEST. This is causing terraform to believe that there are changes in the availability_set

Paul

[ahmetb]

@stack72 I believe Azure Resource Manager APIs reserve right to change casing of the resource name. It sounds like a very silly idea to me as well but this is what it is. Network APIs do it even more aggressively. This is not an SDK issue.

[stack72]

I find this crazy - i am really hoping there is documentation so that I can try to work around this. I understand that URLs should be case insensitive but when it's not documented, it feels crazy

Do you know if the URLs that the API changes the casing of is available? I.e. is availability_set name always UPPERCASE?

P.

[brendandixon]

@stack72 Paul, let me look into this. There was an earlier discussion (another thread, another project) where this came up.

[stack72]

thanks @brendandixon

[johngossman]

Hi @stack72

This has been an endless source of amusing (not) internal conversations about case sensitivity in our URLs and ids. The ARM architecture consists of a frontend that enforces a certain level of consistency and a bunch of individual services. Unfortunately, we didn't catch this one in the frontend and several services choose to normalize segments to their own preferences. Over time I hope we can enforce conformity (which is to always preserve case), but for now I can only cite Postel's Law and the point about URLs being case insensitive: clients should compare ids case insensitively.