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

Ability to specify arbitrary values for environment variables in JRuby container

    Details

    • Type: Task
    • Status: Closed
    • Priority: Normal
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: SERVER 2.6.0
    • Component/s: None
    • Labels:
      None
    • Release Notes:
      New Feature
    • Release Notes Summary:
      Puppet Server now supports the ability to specify a whitelist of environment variables which are made available to Ruby code. This can be done via the 'environment-vars' section under the 'jruby-puppet' configuration section.

      Description

      This is an offshoot of the environment handling consolidation discussed in SERVER-297.

      During the initial development of Puppet Server, a conscious decision was made to shield any Ruby code being executed within Puppet Server’s Java process from directly inheriting any shell environment variables. The primary factor motivating this decision was a fear about the potential contamination of the Puppet Server JRuby runtime by shell environment variables configured for execution under MRI Ruby.

      For example, gems with native C extensions require different implementations for the MRI vs. JRuby execution environments. Assuming the default value for a system's GEM_HOME environment variable, if defined, would most commonly contain a path under which MRI-compatible gems reside, we thought it would be better for the JRuby-based Puppet Server to maintain its own setting for this path which would be completely independent from the shell environment. This is captured under a setting called “gem-home” in the “jruby-puppet” section of the “puppetserver.conf” file. Effectively, the value for this “gem-home” setting is injected into the configuration of the JRuby container in Puppet Server such that Ruby code sees it as the value of the GEM_HOME "environment variable”.

      In current Puppet Server code, GEM_HOME is the only “environment variable” that any Ruby code would see. All other environment variables which may have been active in the shell under which the Puppet Server process was launched - PATH, USER, etc. - are removed / not made visible to any Ruby code running within the Puppet Server process.

      We realized later, however, that by not providing a mechanism for Puppet Server to configure other environment variables into a JRuby container that some Ruby code would be impossible to configure under Puppet Server. For example, assume that your Puppet code needed to make use of a gem that is designed to only be able to read its configuration from an environment variable called FOO. Under current Puppet Server code, it would not be possible for the gem to get a value for this variable.

      To address this use case while preserving the ability to avoid contaminating the JRuby environment with content intended only for use with MRI Ruby, we’ve discussed the possibility of adding an “environment variable” map to the “jruby-puppet” section of the “puppetserver.conf” file.

      For example, assume that an init script had defined a shell environment variable as….

      export FOO=for_mri_ruby
      

      … whereas the “jruby-puppet” section of Puppet Server’s “puppetserver.conf” file were to have:

      jruby-puppet {
        gem-home: /var/lib/puppet/jruby-gems 
        environment-variables: { 
           FOO: for_jruby 
        }
        ...
      }
      

      When the gem mentioned earlier were to access ENV[‘FOO’] while running under Puppet Server, the gem would get a value of “for_jruby”. This would happen because the source of the environment variable for the JRuby container would be drawn from the configuration file as opposed to the actual shell environment.

      The particulars of the API design may need to change a bit before implementation but this ticket is intended to capture the work needed to allow for the population of "custom" environment variables into a JRuby container.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                jeremy.barlow Jeremy Barlow
                QA Contact:
                Kurt Wall
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Zendesk Support