(FM-7145) accelerate puppetserver_gem list

[tkishel]

The puppetserver gem cli commands are particularly slow as they start a JVM.

Instead, for the list command, use the rubygems library from the puppet ruby, setting the GEM_HOME and GEM_PATH to the values in the puppetserver conf file.

The rubygems library does not have access to java platform gems, but java platform gems should not be managed, by design.

[tkishel]

We could also use rubygems for theinstall and uninstall methods and improve their performance (I've tested them) but translating their install_options and uninstall_options from strings to the options hash does not appear to be automatically mappable; and those should occur infrequently enough to accommodate.

[Sharpie]

Might be able to use CRuby for the uninstall, but I'd stick to shelling out to puppetserver gem for install. This is because the installed gem will be used by JRuby, so Java-specific extensions will have to be built instead of C-specific extensions.

[tkishel]

Thanks for the insight! I think accelerating list more meets the 80/20 rule, and keeping the CLI is appropriate for accurate and robust installs/uninstalls given extensions and any internal updating required by the service. Plus, it continues to model the gem provider, making it easier to merge its improvements.

[tkishel]

Once question: this includes 'jruby-gems' 'vendored-jruby-gems' ... but is there another shared (between puppet and puppetserver) gem directory?

[Magisus]

Yes. It lives in /opt/puppetlabs/puppet/lib/ruby/vendor_gems. See https://github.com/puppetlabs/puppetserver/blob/master/resources/ext/config/conf.d/puppetserver.conf#L14. Those are specifically MRI gems, and adding new ones there would not be installed with the puppetserver gem command, but rather puppet's gem command with a special dir specified.

[tkishel]

Perfect, thanks. This would not be for installation, that is not affected by this PR. I'll do some research to see if that shared directory needs to be considered when listing puppetserver gems.

[tkishel]

As per PA-1894 / SERVER-2133 ...

puppetserver gem install writes to:

/opt/puppetlabs/server/data/puppetserver/jruby-gems

puppetserver gem list reads from:

/opt/puppetlabs/server/data/puppetserver/jruby-gems
/opt/puppetlabs/server/data/puppetserver/vendored-jruby-gems
/opt/puppetlabs/puppet/lib/ruby/vendor_gems

Updating this PR to include the vendor_gems path ....

[tphoney]

👍

[tkishel]

Thank you Paula. I've added a commit to address the 2016.4 issue, and another to clean up as many of the remaining robocop issues (caused by updating code previously copied from the gem provider) that I considered practical/safe.

[tkishel]

[root@ark7u58r1xxmobo ~]# facter -p pe_server_version
2016.4.16

[root@ark7u58r1xxmobo ~]#    puppet apply /tmp/puppetserver_gem_install.pp 
Notice: Compiled catalog for ark7u58r1xxmobo.delivery.puppetlabs.net in environment production in 0.79 seconds
Notice: /Stage[main]/Main/Package[world_airports]/ensure: created
Notice: Applied catalog in 14.50 seconds

[root@ark7u58r1xxmobo ~]# puppetserver gem list world_airports

*** LOCAL GEMS ***

world_airports (1.1.3)

[root@ark7u58r1xxmobo ~]# puppet resource package world_airports --param provider
package { 'world_airports':
  ensure   => ['1.1.3'],
  provider => 'puppetserver_gem',
}

[root@ark7u58r1xxmobo ~]#    puppet apply /tmp/puppetserver_gem_uninstall.pp 
Notice: Compiled catalog for ark7u58r1xxmobo.delivery.puppetlabs.net in environment production in 0.77 seconds
Notice: /Stage[main]/Main/Package[world_airports]/ensure: removed
Notice: Applied catalog in 10.04 seconds

[tkishel]

(I and) Every administrator who lost 20 seconds of their lives every time they ran puppet on their masters (after installing this module) thanks all of you for your help with this :)