Use consistent meanings for vm, pool, host and template #186
Description
The terms pool, vm, host and template change meaning in the codebase.
e.g.
https://github.com/puppetlabs/vmpooler/blob/master/lib/vmpooler/pool_manager.rb#L334-L338
Note that we get the template name, but then use it as a pool name
clone_vm is the worst offender
in https://github.com/puppetlabs/vmpooler/blob/master/lib/vmpooler/pool_manager.rb#L199 we find the VM name to clone from (the template) but then in https://github.com/puppetlabs/vmpooler/blob/master/lib/vmpooler/pool_manager.rb#L213 we use template as the pool name. This introduces an error where the VM Template we clone from MUST be named the same as the pool name.
The spec helpers interchangeably use template and pool
In https://github.com/puppetlabs/vmpooler/blob/master/lib/vmpooler/api/v1.rb#L27-L29 the function called pool_exists? takes a single parameter of template
In pool_manager.rb there are a lot calls to host = vsphere.find_vm(vm) however the concept of a host is different in https://github.com/puppetlabs/vmpooler/blob/master/lib/vmpooler/pool_manager.rb#L494 where a host refers to the computer HOSTING the VM
... and so on.
The naming and usage should be modified to be consistent to make it easier to both work on the codebase, and easier to test. I would propose the following definitions:
vm - The short name of a VM (i.e. not the FQDN, but the hostname only). This is normally used as a key in redis etc.
vm_object - An object, of some sort (normally a vSphere object) that represents the VM
pool - The name of a pool of VMs. This is normally used as a key in redis, in the config file (pools)
pool_config - The configuration of a pool from configuration file (usually a hash table)
host - The short name of the computer on which a VM resides
host_object - An object, of some sort (normally a vSphere object) that represents the host on which a VM resides
template - The short name of the VM which is cloned to produce VMs for a pool
Obviously this is not an exhaustive list and there are derivatives of these names e.g. in the VM migration code there will be a current_host and move_to_host concept.