apply
The IP COnfiguration block of `azurerm_network_interface` didn't have a
hash created in a way that changes to the optional params were being
picked up:
```
~ azurerm_network_interface.test
ip_configuration.273485505.name: "testconfiguration1" => ""
ip_configuration.273485505.private_ip_address_allocation: "dynamic" => ""
ip_configuration.273485505.subnet_id: "/subscriptions/34ca515c-4629-458e-bf7c-738d77e0d0ea/resourceGroups/acctestrg/providers/Microsoft.Network/virtualNetworks/acctvn/subnets/acctsub" => ""
ip_configuration.~273485505.load_balancer_backend_address_pools_ids.#: "" => "<computed>"
ip_configuration.~273485505.load_balancer_inbound_nat_rules_ids.#: "" => "<computed>"
ip_configuration.~273485505.name: "" => "testconfiguration1"
ip_configuration.~273485505.private_ip_address: "" => "<computed>"
ip_configuration.~273485505.private_ip_address_allocation: "" => "dynamic"
ip_configuration.~273485505.public_ip_address_id: "" => "${azurerm_public_ip.test.id}"
ip_configuration.~273485505.subnet_id: "" => "/subscriptions/34ca515c-4629-458e-bf7c-738d77e0d0ea/resourceGroups/acctestrg/providers/Microsoft.Network/virtualNetworks/acctvn/subnets/acctsub"
```
This caused the following error:
```
Error applying plan:
1 error(s) occurred:
* azurerm_network_interface.test: diffs didn't match during apply. This is a bug with Terraform and should be reported as a GitHub Issue.
Please include the following information in your report:
```
Notice that the hash didn't change. This change adds the remaining optional params to the hash so that the hash id will change.
```
~ azurerm_network_interface.test
ip_configuration.4255411321.load_balancer_backend_address_pools_ids.#: "" => "<computed>"
ip_configuration.4255411321.load_balancer_inbound_nat_rules_ids.#: "" => "<computed>"
ip_configuration.4255411321.name: "" => "testconfiguration1"
ip_configuration.4255411321.private_ip_address: "" => "<computed>"
ip_configuration.4255411321.private_ip_address_allocation: "" => "dynamic"
ip_configuration.4255411321.public_ip_address_id: "" => "/subscriptions/34ca515c-4629-458e-bf7c-738d77e0d0ea/resourceGroups/acctestrg/providers/Microsoft.Network/publicIPAddresses/public-ip"
ip_configuration.4255411321.subnet_id: "" => "/subscriptions/34ca515c-4629-458e-bf7c-738d77e0d0ea/resourceGroups/acctestrg/providers/Microsoft.Network/virtualNetworks/acctvn/subnets/acctsub"
ip_configuration.966273186.name: "testconfiguration1" => ""
ip_configuration.966273186.private_ip_address_allocation: "dynamic" => ""
ip_configuration.966273186.subnet_id: "/subscriptions/34ca515c-4629-458e-bf7c-738d77e0d0ea/resourceGroups/acctestrg/providers/Microsoft.Network/virtualNetworks/acctvn/subnets/acctsub" => ""
```
This allows the Update to work as expected :)
```
azurerm_network_interface.test: Modifications complete
Apply complete! Resources: 0 added, 1 changed, 0 destroyed.
```
`azurerm_storage_account` access keys
Please note that we do NOT have the ability to manage the access keys -
we are just getting the keys that the account creates for us. To manage
the keys, you would need to use the azure portal still
* Adding private ip address reference
* adding private ip address reference
* Updating the docs.
* Removing optional attrib from private_ip_address
Removing optional attribute from private_ip_address, this element is only being used in the read.
* Selecting the first element instead of using a loop for now.
Change this to a loop when https://github.com/Azure/azure-sdk-for-go/issues/259 is fixed
The `storage_data_disk` was trying to use vhd_url rather than vhd_uri.
This was causing an error on creating a new data_disk as part of a VM
Also added validation as data_disks can only be 1 - 1023 GB in size
ssh_keys were throwing an error similar to this:
```
* azurerm_virtual_machine.test: [DEBUG] Error setting Virtual Machine
* Storage OS Profile Linux Configuration: &errors.errorString{s:"Invalid
* address to set: []string{\"os_profile_linux_config\", \"0\",
* \"ssh_keys\"}"}
```
This was because of nesting of Set within a Set in the schema. By
changing this to a List within a Set, the schema works as expected. This
means we can now set SSH Keys on VMs. This has been tested using a
remote-exec and a connection block with the ssh key
```
azurerm_virtual_machine.test: Still creating... (2m10s elapsed)
azurerm_virtual_machine.test (remote-exec): Connected!
azurerm_virtual_machine.test (remote-exec): CONNECTED!
```
adminPassword
The Azure API never returns the AdminPAssword (as is correct) from the
Read API call. Therefore on Create, we do not set the AdminPassword of
the vm as part of the state. The Same func is used for Create & Update,
therefore when we changed anything on the VM, we were getting the
following error:
```
statusCode:Conflict
serviceRequestId:f498a6c8-6e7a-420f-9788-400f18078921
statusMessage:{"error":{"code":"PropertyChangeNotAllowed","target":"adminPassword","message":"Changing property 'adminPassword' is not allowed."}}
```
To fix this, we need to excldue the AdminPassword from the Update func
if it is empty
The azure tests relating to cdn endpoints (TestAccAzureRMCdnEndpoint_basic
etc) are breaking because ARM is not accepting port values of 0. The
following error is received:
statusCode:BadRequest
statusMessage:{"error":{"code":"BadRequest","message":"Invalid port \"0\". Port value must be a number between 1 and 65535."}}
This patch sets the ports for example.com to 443 and 80.
This commit uses Riviera to register the Microsoft.Compute provider as a
canary for whether or not the Azure account credentials are set up. It
used to use the MS client, but that appeared to panic internally if the
credentials were bad. It's possible that we were using it wrong, but
there are no docs so ¯\_(ツ)_/¯.
As part of this, we parellelise the registration of the other providers.
This shaves the latency of each provider request times the number of
providers minus 1 off the "startup" time of the AzureRM provider. The
result is quite noticeable.
Paul Stack