[JENKINS-44796] Robustness improvements #85
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Bugfix: vSphereCloudSlaveTemplate.provision method now ensures that it always disconnects from vSphere. Previously there were some error cases where this might not happen. Refactor: vSphereCloudSlaveTemplate.provision method now passes in the extra config parameters when the VM is initially created (instead of as a second vSphere operation). This ensures that the meta-data (that we rely on for recognizing our own VMs) is there from the outset and hence we should now be less vulnerable to vSphere failing to power-on the VM after cloning it or to vSphere belatedly starting a VM it claimed to have failed to create. Enhancement: If vSphereCloudSlaveTemplate.provision method failed to clone a new VM, we now attempt to delete the VM, as vSphere can partially-create a VM. Enhancement: VSphere.cloneOrDeployVm method can (optionally) now set extra config parameters.
pjdarton
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
vSphere has a failure mode whereby the clone-and-power-on operation can successfully clone but then fail to power-on.
This can then result in us having a VM in vSphere that we think we failed to create, so we would later "collide" with it.
This can also result in us having a VM in vSphere without the meta-data (stored in the extra-config) that we rely upon to recognize our own VMs, causing us to fail to recognize it as "one of ours" when we do later "collide" with it, meaning that the code introduced in #73 fails to trigger.
The solution is to ensure that the VM is created with the meta-data from the outset, and to always try to delete any VM that didn't create properly (even if vSphere tells us it didn't get created).