the vm_ready methods should be implemented per provider and checking in the api
creates issues since provider code is not available. Removing this for the V2 api
The syntax for pipelined has changed and the old syntax will be removed in v5.0.0
Fixing the syntax now since the block syntax has been supported for a while now.
Before this change if an extra config file had new keys they would get
merged to the main config but if it contained an existing key, like
'providers' it would overwrite the original config.
Adding a library 'deep_merge' to do a more natural merge, where existing keys
get sub-elements added together and arrays are combined like for the
pool configuration.
Adding spec tests around EXTRA_CONFIG as they were missing, by adding
and testing two new extra_config.yaml fixture files
This method should be called only once, when the VM is moved to a running state
which is when the data for the user (if using tokens) is available. In vmpooler
base provider it is a noop method, but the various providers can implement it
to tag or label a running VM with the name of the user who checked it out
vmpooler has the vsphere provider taken out, moving some vsphere related
methods to the provider:
1) pool_folders
2) get_base_folders
At the same time renaming some configuration and code items
to remove harmful terminology.
purge_unconfigured_folders DEPRECATED, use purge_unconfigured_resources
folder_whitelist DEPRECATED, use resources_allowlist
the above configuration items are still supported but will be removed in
the next major version.
base class method purge_unconfigured_folders was renamed to purge_unconfigured_resources
and requires the equivalent change in the provider classes
abc
This implements a delete method for pooltemplate and poolsize. The API
removes the override from Redis and then adds an entry in Redis that
causes the pool manager to wake up and process the removal of the
override.
To facilitate this, a new variable has been created in lib/vmpooler.rb
to hold a copy of the original / pre-override config. This supplemental
copy of the pools is then indexed for use as a reference.
When pool manager wakes up to process an override removal, it looks up
the pre-override value from the config via the new variables mentioned
above.
Just as with entering overrides, no restart is needed. Template and pool
size changes are logged so that anyone watching or reviewing the logs
can see what happened when. The new API endpoints also return values for
both the pre-revert and post-revert value.
