The report in #7378 led us into a deep rabbit hole that turned out to
expose a bug in the graph walk implementation being used by the
`NoopTransformer`. The problem ended up being when two nodes in a single
dependency chain both reported `Noop() -> true` and needed to be
removed. This was breaking the walk and preventing the second node from
ever being visited.
Fixes#7378
This fixes the `TestAccAWSBeanstalkEnv_tier` test. The instance profile
needs access to send and receive messages from its sqs queue. Without
these permissions Beanstalk returns an error event, causing the test to
fail.
The ICMP type 0 (Echo Reply) was not handled correctly. This commit changes the
type of attributes "icmp_type" and "icmp_code" from TypeInt to TypeString,
allowing for the string value to be manually converted into an integer. This
enables an integer values such as -1, 0, 8, etc., coming from the resource
definition in the template to be handled correctly.
Signed-off-by: Krzysztof Wilczynski <krzysztof.wilczynski@linux.com>
Neither skip_final_snapshot nor final_snapshot_identifier can be fetched
from any API call, so we need to default skip_final_snapshot to true
during import so that final_snapshot_identifier is not required
The error was ignored causing Terraform to report that the deployments was
successful rather than in a bad state. This commit cause the apply operation
to report the error.
Added a test which attempts to create a storage account with a name longer
than the maximum permitted length to force a failure.
```
TF_ACC=1 go test ./builtin/providers/azurerm -v -run TestAccAzureRMTemplateDeployment_ -timeout 120m
=== RUN TestAccAzureRMTemplateDeployment_basic
--- PASS: TestAccAzureRMTemplateDeployment_basic (377.78s)
=== RUN TestAccAzureRMTemplateDeployment_withParams
--- PASS: TestAccAzureRMTemplateDeployment_withParams (327.89s)
=== RUN TestAccAzureRMTemplateDeployment_withError
--- PASS: TestAccAzureRMTemplateDeployment_withError (226.64s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/azurerm 932.440s
```
ForceNew
```
% make testacc TEST=./builtin/providers/azurerm TESTARGS='-run=TestAccAzureRMVirtualMachine_ChangeComputerName'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
TF_ACC=1 go test ./builtin/providers/azurerm -v
-run=TestAccAzureRMVirtualMachine_ChangeComputerName -timeout 120m
=== RUN TestAccAzureRMVirtualMachine_ChangeComputerName
--- PASS: TestAccAzureRMVirtualMachine_ChangeComputerName (965.04s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/azurerm
965.051s
```
The tests were removed due to a nil pointer panic in
testCheckAzureRMVirtualMachineOSDiskVHDExistance when the storage account itself
had been deleted in the destroy stage
Added a test to cover opting out of VHD delete rather than polluting the basic
linux VM test.
```
TF_ACC=1 go test ./builtin/providers/azurerm -v -run TestAccAzureRMVirtualMachine_deleteVHDOpt -timeout 120m
=== RUN TestAccAzureRMVirtualMachine_deleteVHDOptOut
--- PASS: TestAccAzureRMVirtualMachine_deleteVHDOptOut (731.54s)
=== RUN TestAccAzureRMVirtualMachine_deleteVHDOptIn
--- PASS: TestAccAzureRMVirtualMachine_deleteVHDOptIn (590.87s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/azurerm 1322.529s
```
```
TF_ACC=1 go test ./builtin/providers/azurerm -v -run TestAccAzureRMVirtualMachine_basicLinuxMachine -timeout 120m
=== RUN TestAccAzureRMVirtualMachine_basicLinuxMachine
^[--- PASS: TestAccAzureRMVirtualMachine_basicLinuxMachine (587.63s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/azurerm 587.738s
```
* provider/azurerm: destroy azurerm_virtual_machine OS Disk VHD on deletion
The OS Disk previously wasn't deleted with the VM, this causes subsequent
apply operations which recreate the VM to fail as the VHD blob already exists.
Fixes#6610
* provider/azurerm: add delete_os_disk_on_termination to azurerm_virtual_machine
delete_os_disk_on_termination is a bool which defaults to false to avoid making
a breaking change, and to follow the same flow as the Azure API
Needed to change the test due to SQS having issues recreating the same
queue multiple times. Now it uses a random name
```
make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSSQSQueue_'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /vendor/)
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSSQSQueue_
-timeout 120m
=== RUN TestAccAWSSQSQueue_importBasic
--- PASS: TestAccAWSSQSQueue_importBasic (20.53s)
=== RUN TestAccAWSSQSQueue_basic
--- PASS: TestAccAWSSQSQueue_basic (33.85s)
=== RUN TestAccAWSSQSQueue_redrivePolicy
--- PASS: TestAccAWSSQSQueue_redrivePolicy (26.59s)
=== RUN TestAccAWSSQSQueue_Policybasic
--- PASS: TestAccAWSSQSQueue_Policybasic (36.92s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 117.908s
```
Soooo many missing fields not being set on the Read!
```
% make testacc TEST=./builtin/providers/azurerm TESTARGS='-run=TestAccAzureRMNetworkSecurityRule_'
==> Checking that code complies with gofmt requirements...
/Users/stacko/Code/go/bin/stringer
go generate $(go list ./... | grep -v /terraform/vendor/)
2016/07/13 21:34:24 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/azurerm -v
-run=TestAccAzureRMNetworkSecurityRule_ -timeout 120m
=== RUN TestAccAzureRMNetworkSecurityRule_importBasic
--- PASS: TestAccAzureRMNetworkSecurityRule_importBasic (208.10s)
=== RUN TestAccAzureRMNetworkSecurityRule_basic
--- PASS: TestAccAzureRMNetworkSecurityRule_basic (190.66s)
=== RUN TestAccAzureRMNetworkSecurityRule_addingRules
--- PASS: TestAccAzureRMNetworkSecurityRule_addingRules (256.73s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/azurerm
655.514s
```
* Add scaleway provider
this PR allows the entire scaleway stack to be managed with terraform
example usage looks like this:
```
provider "scaleway" {
api_key = "snap"
organization = "snip"
}
resource "scaleway_ip" "base" {
server = "${scaleway_server.base.id}"
}
resource "scaleway_server" "base" {
name = "test"
# ubuntu 14.04
image = "aecaed73-51a5-4439-a127-6d8229847145"
type = "C2S"
}
resource "scaleway_volume" "test" {
name = "test"
size_in_gb = 20
type = "l_ssd"
}
resource "scaleway_volume_attachment" "test" {
server = "${scaleway_server.base.id}"
volume = "${scaleway_volume.test.id}"
}
resource "scaleway_security_group" "base" {
name = "public"
description = "public gateway"
}
resource "scaleway_security_group_rule" "http-ingress" {
security_group = "${scaleway_security_group.base.id}"
action = "accept"
direction = "inbound"
ip_range = "0.0.0.0/0"
protocol = "TCP"
port = 80
}
resource "scaleway_security_group_rule" "http-egress" {
security_group = "${scaleway_security_group.base.id}"
action = "accept"
direction = "outbound"
ip_range = "0.0.0.0/0"
protocol = "TCP"
port = 80
}
```
Note that volume attachments require the server to be stopped, which can lead to
downtimes of you attach new volumes to already used servers
* Update IP read to handle 404 gracefully
* Read back resource on update
* Ensure IP detachment works as expected
Sadly this is not part of the official scaleway api just yet
* Adjust detachIP helper
based on feedback from @QuentinPerez in
https://github.com/scaleway/scaleway-cli/pull/378
* Cleanup documentation
* Rename api_key to access_key
following @stack72 suggestion and rename the provider api_key for more clarity
* Make tests less chatty by using custom logger
stack72