Prior to this commit the pooler had no awareness of the complete set of
hostnames that are currently in use. This meant that it was possible to
allocate the same hostname twice, which would result in the original
host with that hostname becoming unreachable.
This commit adds a check for the existence of the
`vmpooler__vm__<hostname>` key before attempting to clone the vm.
This should prevent duplicate hostnames.
If the hostname is already taken, `_clone_vm` will retry with a new
random hostname multiple times before raising an exception.
Previously, there were some rubocop rule names that were causing rubocop
to fail to run entirely.
This commit updates the rubocop configs to match the new rubocop rule
names so that we can see all the issues that need correcting.
Prior to this commit the hostname_shorten regex wouldn't match the
updated human readable hostnames because they contain dashes.
This commit updates the regex to capture dashes in the hostname, and
adds a few specs to verify that behavior.
This commit adds the spicy-proton gem to vmpooler.gemspec. Without this change the spicy-proton gem is in the Gemfile, but not the gemspec, causing issues when deploying from gem.
Prior to this commit hostnames for VMs provisioned by vmpooler were 15
random characters. This is difficult for humans to tell apart.
This commit updates the naming to use the `spicy-proton` gem to generate
adjective noun pair names for the VMs, which I think would be easier for
humans to tell apart, as well as fun and memorable to say.
The random name should not exceed 15 characters in order to prevent
issues with NETBIOS, etc as discussed in the attached ticket.
This commit updates the way that checkoutlock is defined so it is not passed through bin/vmpooler. Without this change there's an unnecessary layer the mutex passes through.
This commit adds a shared mutex to vmpooler API so that checkout requests can be synchronized across threads. Without this change it is possible in some scenarios for vmpooler to allocate the same SUT to different API requests for a VM.
The host['boottime'] variable in the function _check_ready_vm no longer
has its parent object in reference due to the refactoring in pull
request #269. So in order to get the same information without the
performance impact from duplicate object lookups, we get similar
information from the time that the VM is ready.
This commit updates the create_linked_clone pool option to correctly detect when linked clones have been set at a pool level. Without this change a pool setting create_linked_clone to false is not interpreted correctly, and a linked clone is created if possible.
This change adds the running host for a VM to the API data available via /vm/hostname. Without this change the running host would be logged to vmpooler log, but not available any other way. Additionally, the data will specify if a machine has been migrated. Without this change parent host data for a vmpooler machine is not available via the vmpooler API.
This commit adds a new configuration parameter to allow setting whether to create linked clones on a global, or per pool basis. Without this change vmpooler would always attempt to create linked clones. The default behavior of creating linked clones is preserved.
This allows the user to change the cluster in which the targeted pool
will clone to. Upon configuration change, the thread will wake up and
execute the change within 1 second.
This commit updates the reference to domain from vmpooler config. Without this change the domain value is read as an empty string and breaks checkouts.
This commit duplicates the vm_ready? check to the API layer to allow for API to validate that a VM is alive at checkout. Without this change API relies upon the checks in pool_manager validating pools. This change should allow for additional insight into whether a machine is in a ready state and resopnding at checkout time.
