[SERVER-522] Temporarily undo `puppetserver gem env` fix from SERVER-262 Created: 2015/03/26  Updated: 2015/04/21  Resolved: 2015/03/26

Status: Closed
Project: Puppet Server
Component/s: None
Affects Version/s: SERVER 1.0.2
Fix Version/s: SERVER 1.0.3

Type: Task Priority: Normal
Reporter: Jeremy Barlow Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relates to SERVER-262 `puppetserver gem env` does not work,... Closed
relates to SERVER-377 "puppetserver gem" command doesn't wo... Closed
relates to SERVER-297 Consolidate environment variable hand... Closed
Sub-team: emerald
Story Points: 1
QA Contact: Erik Dasher


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.

Generated at Sat Aug 08 09:02:07 PDT 2020 using Jira 8.5.2#805002-sha1:a66f9354b9e12ac788984e5d84669c903a370049.