There were 2 issues when changing machine networks:
When a machine was being marked as deleted, we were waiting for the
machine state to become deleted and therefore, we were missing that Triton
was sending a status code of 410 (StatusGone) back to Terraform
Once we actually handled the correct StatusCode, we managed to notice that
we were trying to remove and delete ALL of the nics each time an update was
found in the NICs
By fixing up the differencing of the NIC []string{}, we managed to get the
correct behaviour. This now means that we will no longer have an unstable
TestAccTritonMachine_addNIC acceptance test
terraform-provider-triton [networks-cleanup●] % acctests triton TestAccTritonMachine
=== RUN TestAccTritonMachine_basic
--- PASS: TestAccTritonMachine_basic (96.97s)
=== RUN TestAccTritonMachine_affinity
--- PASS: TestAccTritonMachine_affinity (98.99s)
=== RUN TestAccTritonMachine_dns
--- PASS: TestAccTritonMachine_dns (180.34s)
=== RUN TestAccTritonMachine_nic
--- PASS: TestAccTritonMachine_nic (183.41s)
=== RUN TestAccTritonMachine_addNIC
--- PASS: TestAccTritonMachine_addNIC (274.04s)
=== RUN TestAccTritonMachine_firewall
--- PASS: TestAccTritonMachine_firewall (98.24s)
=== RUN TestAccTritonMachine_metadata
--- PASS: TestAccTritonMachine_metadata (135.68s)
=== RUN TestAccTritonMachine_cns
--- PASS: TestAccTritonMachine_cns (194.99s)
=== RUN TestAccTritonMachine_locality
--- PASS: TestAccTritonMachine_locality (378.14s)
PASS
ok github.com/terraform-providers/terraform-provider-triton/triton 1640.828s
There were 2 issues when changing machine networks:
Once we actually handled the correct StatusCode, we managed to notice that we were trying to remove and delete ALL of the nics each time an update was found in the NICs
By fixing up the differencing of the NIC []string{}, we managed to get the correct behaviour. This now means that we will no longer have an unstable
TestAccTritonMachine_addNIC
acceptance test