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
As per best practices, removed duplication between the Gemfile and gemspec.
There was also some seemingly superfluous install in the Gemfile.
Ordered the dependency by alphabetical order.
Tested locally by deleting the .bundle and recreating successfully
This change utilizes OpenTelemetry's automatic instrumentation to add
distributed tracing capabilities to VMPooler. This is a non-breaking
change as traces are processed in noop mode by default.
This change updates vmpooler to test ruby 2.5.8, and jruby 9.2.12.0. Without this change vmpooler tests against 2.5.7 and jruby 9.2.9.0. Additionally, testing on 2.4.x is removed. Lastly, rubocop tests are updated to run on 2.5.8.
