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.
```
* provider/datadog Update go-datadog-api.
* provider/datadog Add support for "require_full_window" and "locked".
* provider/datadog Update tests, update doco, gofmt.
* provider/datadog Add options to update resource.
* provider/datadog "require_full_window" defaults to True, "locked" to False. Use
those initial values as the starting configuration.
* provider/datadog Update notify_audit tests to use the default value for
testAccCheckDatadogMonitorConfig and a custom value for
testAccCheckDatadogMonitorConfigUpdated.
This catches a situation where the code ignores setting the option on creation,
and the update function merely asserts the default value, versus actually changing
the value.
Building on b10564a, adding tweaks that allow the module var count
search to act recursively, ensuring that a sitaution where something
like var.top gets passed to module middle, as var.middle, and then to
module bottom, as var.bottom, which is then used in a resource count.
A new problem was introduced by the prior fixes for destroy
interpolation messages when resources depend on module variables with
a _count_ attribute, this makes the variable crucial for properly
building the graph - even in destroys. So removing all module variables
from the graph as noops was overzealous.
By borrowing the logic in `DestroyEdgeInclude` we are able to determine
if we need to keep a given module variable relatively easily.
I'd like to overhaul the `Destroy: true` implementation so that it does
not depend on config at all, but I want to continue for now with the
targeted fixes that we can backport into the 0.6 series.
This commit forward ports the changes made for 0.6.17, in order to store
the type and sensitive flag against outputs.
It also refactors the logic of the import for V0 to V1 state, and
fixes up the call sites of the new format for outputs in V2 state.
Finally we fix up tests which did not previously set a state version
where one is required.
`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
