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.
Prior to this, the encryption settings for LDAP auth were hard coded to
start_tls on port 389 with TLSv1. These are still the defaults, as
insecure as they are, so as to not break existing users. This change
facilitates replacing the defaults so that simple_tls over port 636 via
TLS1.2 can be used.
This adds an "operation" label to the user metrics and moves incrementing from the manager to api, so that the user metrics show when resources are allocated, as well as destroyed. Previously, user metrics were only updated upon destroying a resource.
I think its better suited to increment the metric as part of the api instead of the pool_manger, because it's expected to do so when a user successfully checks out or deletes a VM, but can be problematic when doing so in the provider since it can clone VMs before actually being checked out by a user.
It appears we renamed `/ondemand/` to `/ondemandvm/` at some point and,
as a result, have not been stripping hostnames from that endpoint's
metrics. This has caused issues with metrics collection due a very high
cardinality.
This change removes usage of redis multi from API. Without this change the redis usage can cause issues because no connection pool is used, so another worker may try to use the same backend object causing a failure.
Checkout metric counters were against the template name and not the
actual pool used which prevents us from counting the checkouts in the
pixa4 pools for example.
Note - this is a re-rerun - the last commit on this file over-wrote
the change.
This change fixes an error in validate_token where hset does not have the correct number of parameters. Without this change validate_token causes a error.
This change sets a VM as running in redis as soon as it is checked out. Without this change when allocated several instances it is possible for a machine that has been allocated for a checkout, but not yet marked as active, to be identified as running when it should not be, which was added in POOLER-191. Without this change a machine may be destroyed during checkout by pool_manager if there are several instances being allocated.
Additionally, redis multi is added for vm checkout operations to minimize the round trips to redis during a checkout operation. Without this addition each VM checkout causes several redis interactions.
Checkout metric counters were against the template name and not the
actual pool used which prevents us from counting the checkouts in the
pixa4 pools for example.
* (maint) Speedup the tagging method
While looking at the instrumentation data for the ABS queue processor,
I noticed a lot of time spent in the HTTP PUT method, which in the code
was easy to isolate, as it is only used via the vmpooler tagging functions
ie the API /vm/foobar/ with 'tag' key-value pairs.
While I'm not sure the original hset() make sense to me, there was an easy
way to speed them up by using pipelined. I would expect a very good speed
increase with this turned on.
* tag rubocop to <1.0 because the 1.0 version returns 130 new offenses
This change adds detection of running instances that are in a running
queue, but have no data in a active queue for the same pool. When this
happens a machine will live forever, impacting the running count, and
preventing the machine from being killed. Without this change running
instances that are not marked as active will live forever.
This update includes two key benefits:
1. Spans will be named based on their route instead of the full path
info thanks to https://github.com/open-telemetry/opentelemetry-ruby/pull/415
2. Helper methods were added to the configurator to simplify setting
service.name and service.version
