[Ramesh7]

Summary

P4DEVOPS-16617. Updates vmpooler's gem dependencies as far as JRuby 9.4 (Ruby 3.1, what prod runs) allows, and fixes the one regression the update causes. Against main (3.8.1, after #705), with only the changes the update needs. This is the dependency part of #704 without the test-coverage work from #703.

The newest OpenTelemetry instrumentation needs Ruby 3.3 or later, so "latest" is not reachable on this runtime. These are the highest versions that run on Ruby 3.1.

Changes

• Version 3.8.1 -> 4.0.0 (lib/vmpooler/version.rb, the vmpooler entry in Gemfile.lock, CHANGELOG.md). Major, because the gemspec's OpenTelemetry requirements change and anything locking vmpooler with the old instrumentation gems has to move with it. The changelog entry is written by hand, not generated.

• Gemfile.lock: runtime and test gems updated to the newest versions the gemspec already allows. The lint toolchain (rubocop-ast, prism, parser) is untouched.

• vmpooler.gemspec: the exact = pins on the OpenTelemetry gems become patch-level ranges at the highest versions that run on Ruby 3.1:

  Gem	Was	Now
  instrumentation-concurrent_ruby	= 0.21.1	~> 0.23.1
  instrumentation-http_client	= 0.22.2	~> 0.25.1
  instrumentation-rack	= 0.23.4	~> 0.28.2
  instrumentation-redis	= 0.25.3	~> 0.27.1
  instrumentation-sinatra	= 0.23.2	~> 0.27.1
  sdk	~> 1.8	~> 1.10
  exporter-jaeger, resource_detectors	exact	~> at the same version

• lib/vmpooler.rb: use_rack_events: false for the Rack instrumentation. From instrumentation-rack 0.26 the Rack events handler detaches the OpenTelemetry context when Puma closes the response body, not where it was attached. OpenTelemetry then logs calls to detach should match corresponding calls to attach at ERROR, about three times per request.

Verification

• On this branch, JRuby 9.4.7 in Docker, with the committed Gemfile.lock: bundle exec rspec spec gives 893 examples, 0 failures. The runtime gem versions resolved there are identical to the committed lock.

• Real vmpooler API in containers with an explicit lockfile each, same config, Redis and Jaeger, 6 marked requests (measured on the P4DEVOPS-16617: update gem dependencies within what JRuby 9.4 can run (stacked on #703) #704 branch, same dependency set):

  Gem set	Traces in Jaeger	Detach errors
  Prod's set (instrumentation-rack 0.23.4, SDK 1.8)	6	0
  New gems, events handler on (default)	6	21
  New gems, events handler off (this PR)	6	0

Not verified

• Rubocop on this branch. prism needs a C compiler that the test container does not have, so the lint gems were not installed. CI runs it.
• A spec for use_rack_events: false. spec/unit/vmpooler_config_spec.rb is added by P4DEVOPS-16617: raise test coverage to 93% and fix bugs it found #703 and does not exist on main. P4DEVOPS-16617: update gem dependencies within what JRuby 9.4 can run (stacked on #703) #704 carries the spec. Say if you want a small spec file added here.
• A deployment through the vmpooler-deployment image and a cluster, and anything beyond the API process (the manager was not run on the new set).

Not in this PR

• Major upgrades (sinatra 4, rack 3, puma 7/8, redis 6, prometheus-client 5, connection_pool 3). Each is a breaking change and should go one at a time behind the test suite.
• vmpooler-deployment: it consumes the released gem, so it needs a vmpooler release first, then a regenerated docker/Gemfile.lock.

Relation to other PRs

• P4DEVOPS-16617: update gem dependencies within what JRuby 9.4 can run (stacked on #703) #704 is the same change stacked on P4DEVOPS-16617: raise test coverage to 93% and fix bugs it found #703. Once this merges, P4DEVOPS-16617: update gem dependencies within what JRuby 9.4 can run (stacked on #703) #704 can be closed or rebased onto main and reduced to the spec.

🧙 Built with WOZCODE