Uploaded image for project: 'Puppet Server'
  1. Puppet Server
  2. SERVER-522

Temporarily undo `puppetserver gem env` fix from SERVER-262



    • Type: Task
    • Status: Closed
    • Priority: Normal
    • Resolution: Done
    • Affects Version/s: SERVER 1.0.2
    • Fix Version/s: SERVER 1.0.3
    • Component/s: None
    • Labels:
    • Template:
    • Sub-team:
    • Story Points:


      SERVER-262 documented a failure that occurs when running `puppetserver gem env`:

      [vagrant@localhost ~]$ puppetserver gem env
      ERROR:  While executing gem ... (NoMethodError)
          undefined method `split' for nil:NilClass

      The fix that was done for SERVER-262 did address the error that occurred when "puppetserver gem env" was done. In the process, however, the handling for the GEM_PATH environment variable for "puppetserver gem" changed. Prior to the change in SERVER-262, the GEM_PATH environment variable had been set on the JRuby environment within the puppetserver process as an empty string. The changes in SERVER-262, however, allowed whatever value may have existed in the user's external environment for GEM_PATH to be passed on through unaltered to the JRuby environment within the puppetserver process. The GEM_PATH environment variable, however, continued to be set as an empty string in the context of the normal puppetserver service startup.

      The new behavior for GEM_PATH created concern for some that users might encounter confusion around the following possible scenario:

      1) User had a value set in the external environment for GEM_PATH which included a directory where the MRI/system Ruby would install / look for gems.

      2) User had used the MRI/system Ruby gem command to install a gem into that directory, e.g., "nokogiri."

      3) User ran "puppetserver gem list" and saw that "nokogiri" appeared to be installed. In this case, it would be the "nokogiri" to be used with MRI/system Ruby, not a JRuby-compatible "nokogiri" - however, this distinction may not be obvious to the user.

      4) Assuming that the "nokogiri" gem had properly been installed for Puppet Server to use, user starts Puppet Server service. Some of the user's Ruby code that references "nokogiri" would blow up because "nokogiri" couldn't be found via either GEM_HOME or GEM_PATH.

      Rather than rework the initial work done for SERVER-262 to allow for the "puppetserver gem env" command to still work while alleviating potential confusion which could arise from the new GEM_PATH handling behavior, the original PR for SERVER-262 was reverted for the SERVER 1.0.3 release.

      SERVER-297 was submitted as a follow-on request to cover a more robust implementation for Ruby environment variable handling behaviors for Puppet Server. The work to restore "puppetserver gem env" to working order should be done along with the other work in that ticket.


          Issue Links



              Unassigned Unassigned
              jeremy.barlow Jeremy Barlow
              QA Contact:
              Erik Dasher Erik Dasher
              0 Vote for this issue
              1 Start watching this issue



                  Zendesk Support