These resources use ARM to get keys for the storage API, but then use
the storage REST API as per the ASM provider. The code is significantly
reworked with better logging and error handling. The key functions can
be reused for queues and file storage resources when they get added.
This is an unusual resource (so far) in that it cannot be created in one
call, and instead must be created and the modified to set some of the
parameters.
We use the pollIndefinitelyWhileNeeded function which will continue to
poll Azure RM operation monitoring endpoints until an error is reported
or the operation meets one of the given status codes. The function was
originally part of this feature but was separated out in order to
unblock other work.
Currently there is no support for the "custom_domain" section of the
storage account API. This was originally present and was later taken out
of the scope of the storage account resource in order that the following
workflow can be used:
1. Create storage account
2. Create DNS CNAME entry once the account name is known
3. Create custom domain mapping
- Add documentation for resources
- Rename files to match standard patterns
- Add acceptance tests for resource groups
- Add acceptance tests for vnets
- Remove ARM_CREDENTIALS file - as discussed this does not appear to be
an Azure standard, and there is scope for confusion with the
azureProfile.json file which the CLI generates. If a standard emerges
we can reconsider this.
- Validate credentials in the schema
- Remove storage testing artefacts
- Use ARM IDs as Terraform IDs
- Use autorest hooks for logging
This commit cleans up some of the work on the Azure ARM provider
following review by @phinze. Specifically:
- Unnecessary ASM-targeted tests are removed
- Validation is added to the `resource_group` resource
- `dns_servers_names` -> `dns_servers` as per the API documentation
- AZURE_SUBSCRIPTION_ID environment variable is renamed to be
ARM_SUBSCRIPTION_ID in order to match the other environment variables
This commit brings some of the work over from #3808, but rearchitects to
use a separate provider for Azure Resource Manager. This is in line with
the decisions made by the Azure Powershell Cmdlets, and is important for
usability since the sets of required fields change between the ASM and
ARM APIs.
Currently `azurerm_resource_group` and `azurerm_virtual_network` are
implemented, more resources will follow.
stack72