In a lot of test-cases, I received a timeout when creating an machine:
=== RUN TestAccTritonMachine_basic
--- FAIL: TestAccTritonMachine_basic (653.80s)
testing.go:435: Step 0 error: Error applying: 1 error(s) occurred:
* triton_machine.test: 1 error(s) occurred:
* triton_machine.test: timeout while waiting for state to become 'running' (last state: 'provisioning', timeout: 10m0s)
AFAICT, this was because the StateChangeConf func was returning machineStateProvisioning by default - not the actual state. Therefore, Terraform wasn't actually always able to tell if it had reached the desired state. By returning inst.State rather than assuming it was provisioning, I was able to get a more consistent test run.
HTTP_PROXY=http://127.0.0.1:8888 make testacc TEST=./triton TESTARGS='-run=TestAccTritonMachine_basic'
==> Checking that code complies with gofmt requirements...
TF_ACC=1 go test ./triton -v -run=TestAccTritonMachine_basic -timeout 120m
=== RUN TestAccTritonMachine_basic
--- PASS: TestAccTritonMachine_basic (88.36s)
PASS
ok github.com/terraform-providers/terraform-provider-triton/triton 88.381s
In a lot of test-cases, I received a timeout when creating an machine:
AFAICT, this was because the StateChangeConf func was returning
machineStateProvisioning
by default - not the actual state. Therefore, Terraform wasn't actually always able to tell if it had reached the desired state. By returninginst.State
rather than assuming it wasprovisioning
, I was able to get a more consistent test run.//cc jen20 @sean-