The XO api gracefully shutdowns VMs when it can detect that the VM is using Xen PV drivers (source).
The terraform provider is only issuing graceful shutdowns and is implictly relying on the fact that VMs have the Xen management agent detected before a shutdown is issued (in the test suite and when users use the provider).
I discovered this issue when writing an acceptance test for #212. It's also causing flakiness in the acceptance test suite. This can be seen on master by running the TestAccXenorchestraVm_diskAndNetworkAttachmentIgnoredWhenHalted test individually rather than as part of the entire test suite.
$ TEST=TestAccXenorchestraVm_diskAndNetworkAttachmentIgnoredWhenHalted make testacc
[ ... ]
resource_xenorchestra_vm_test.go:1397: failed to halt VM with error: jsonrpc2: code 14 message: VM lacks feature : {"objectId":"195f07f5-c699-a270-3a31-a9eaafc54af3"}
--- FAIL: TestAccXenorchestraVm_diskAndNetworkAttachmentIgnoredWhenHalted (49.81s)
This is because running go tests in parallel causes them to pause before execution is later resumed, masking this failure.
By ensuring that that PV privers are present we can issue graceful shutdowns without race conditions. We likely will want to consider if the client should optionally issue forceful shutdowns after a period of time. However that will require more consideration to determine the right heuristics and I'd like to investigate how the XO api handles this.
The XO api gracefully shutdowns VMs when it can detect that the VM is using Xen PV drivers (source).
The terraform provider is only issuing graceful shutdowns and is implictly relying on the fact that VMs have the Xen management agent detected before a shutdown is issued (in the test suite and when users use the provider).
I discovered this issue when writing an acceptance test for #212. It's also causing flakiness in the acceptance test suite. This can be seen on master by running the
TestAccXenorchestraVm_diskAndNetworkAttachmentIgnoredWhenHaltedtest individually rather than as part of the entire test suite.This is because running go tests in parallel causes them to pause before execution is later resumed, masking this failure.
By ensuring that that PV privers are present we can issue graceful shutdowns without race conditions. We likely will want to consider if the client should optionally issue forceful shutdowns after a period of time. However that will require more consideration to determine the right heuristics and I'd like to investigate how the XO api handles this.