Use consistent meanings for vm, pool, host and template

[glennsarti]

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.

[glennsarti]

As far as implementation. I would probably start with renaming the variables in the spec tests and then look at renaming the code itself.

[yachub]

We're migrating issue management to Jira, so tracking this has been moved to https://puppet.atlassian.net/browse/POOLER-221

[yachub]

We're migrating issue management to Jira, so tracking this has been moved to https://puppet.atlassian.net/browse/POOLER-221

Apologies for the noise, we went full circle here and decided to move from Jira Cloud to GitHub Projects instead.