r/virtual_machine: Enforce powered on state #152
Conversation
This commit adds something that we generally assume is correct in Terraform - that an instance's power state is either one of two states: on, or gone. vsphere_virtual_machine has had a couple of issues that have been attributed to power state in the last few months that have been fixed, but the issue of ensuring that VMs are always powered on has not been touched on yet. In this commit, we add the `power_state` pseudo-computed variable, working around the fact that the provider can't manipulate the diff directly by using an immutable default to always indicate that a VM that is powered off or suspended will be turned back on during the next Terraform run. If a VM is powered off, this turns the VM back on during the configuration modification phase at the end of the update. Fixes #134. Related to #103.
| // copyStatePtr returns a TestCheckFunc that copies the reference to the test | ||
| // run's state to t. This allows access to the state data in later steps where | ||
| // it's not normally accessible (ie: in pre-config parts in another test step). | ||
| func copyStatePtr(t **terraform.State) resource.TestCheckFunc { |
There was a problem hiding this comment.
Are the pointers to pointers necessary?
There was a problem hiding this comment.
Double pointer rationale here.
| resource.TestStep{ | ||
| Config: config, | ||
| Check: resource.ComposeTestCheckFunc( | ||
| copyStatePtr(&state), |
There was a problem hiding this comment.
If we didn't do a pointer to a pointer with the above comment we could just pass state instead of &state. Unless I'm missing something
There was a problem hiding this comment.
Yeah, the double pointer is necessary because a terrafrom.State instance is always passed by reference. So we need to directly modify the value of the pointer, or else it's essentially passed by value and does not get retained. Example of a failure of a pass by value function. Unless I'm missing something. :)
A different approach would be to use State.Copy, but I don't necessarily want a copy here, but instead the in-flight state.
|
Hey @mbfrahry, also, we actually want a non-empty plan here on powered down (there is actually a test in master testing this right now) because we always want to diff Unfortunately with the current state of affairs with Reference to the existing test: https://github.com/terraform-providers/terraform-provider-vsphere/blob/master/vsphere/resource_vsphere_virtual_machine_test.go#L300 |
ghost
locked and limited conversation to collaborators
This commit adds something that we generally assume is correct in
Terraform - that an instance's power state is either one of two states:
on, or gone.
vsphere_virtual_machinehas had a couple of issues that have beenattributed to power state in the last few months that have been fixed,
but the issue of ensuring that VMs are always powered on has not been
touched on yet.
In this commit, we add the
power_statepseudo-computed variable,working around the fact that the provider can't manipulate the diff
directly by using an immutable default to always indicate that a VM that
is powered off or suspended will be turned back on during the next
Terraform run. If a VM is powered off, this turns the VM back on during
the configuration modification phase at the end of the update.
Fixes #134.
Related to #103.