Thanks for the responses on this thread so far and some of the 
corresponding discussion that has been spawned in the related JIRA ticket 
- https://tickets.puppetlabs.com/browse/SERVER-297.

On Tuesday, April 14, 2015 at 9:09:40 AM UTC-7, Nan Liu wrote:
>
> On Tuesday, April 14, 2015 at 4:35:29 AM UTC-7, Ken Barber wrote:
>>
>> > While we are leaning toward a config-file driven approach, we would be 
>> > interested in hearing of any specific use cases you may know of where 
>> this 
>> > may be insufficient.  We would specifically be interested in any use 
>> cases 
>> > which suggest that some affordance in the design should be made to 
>> allow for 
>> > some (or all?) variables seen by Ruby code to be drawn from the actual 
>> shell 
>> > environment, as opposed to just a configuration file. 
>>
>> Might be clutching at straws here, but there might be a case for 
>> something like http_proxy (which is a reasonably common convention) in 
>> a closed environment that requires it, to be just passed through, 
>> versus defining it also in another configuration file again. That kind 
>> of environment var is _sometimes_ set globally to avoid configuring 
>> the proxy config in all the different clients/services that a *nix box 
>> has. I think Net::HTTP honors this environment variable for example, 
>> so this might apply to some functions that make outbound http calls. 
>>
>
> +1, http_proxy and no_proxy not being honored in puppet functions is one 
> of the annoyances I've run into with puppet-server. 
>
> Of course, I'd rather here what the community has to say about this. 
>> Maybe users would prefer to manage this more precisely instead of 
>> globally anyway from a puppetserver/function perspective. 
>
>
> I'm fine explicitly setting environment variable for puppetserver if 
> there's an option to passthrough
>

Most of the discussion I've seen about this so far has centered on the lack 
of an ability for Puppet Server to use a proxy for HTTP/S communications 
when needed.  This has been mostly with respect to the "puppetserver gem" 
command being unable to access gem repositories via a proxy - also covered 
in https://tickets.puppetlabs.com/browse/SERVER-377.  Proxy support is an 
issue that clearly needs to be addressed, both for puppetserver CLI tools 
and the production Puppet Server stack.  See 
https://tickets.puppetlabs.com/browse/SERVER-156 around the production 
Puppet Server stack's current lack of support for using a proxy.

We will certainly need to get to a solution that allows for values for the 
*_PROXY variables to be made available to Ruby code running in a JRuby 
container in Puppet Server.  I think there's also a very reasonable case to 
be made that these specific variables be drawn from the actual shell 
environment, when not overridden by Puppet Server configuration, given that 
they are very commonly used to perform system-wide proxy configuration that 
many tools honor as defaults.

What is not clear to me at this point, though, is whether the *_PROXY 
variable case alone is enough to inform the more general approach that we 
take toward environment variable population into the JRuby containers - and 
specifically whether or not there is a requirement to provide a 
more-general purpose mechanism for choosing arbitrary variables to flow 
through from the shell environment to the JRuby container.

I'd like to hear if anyone has other use cases - ones not related to 
*_PROXY - for flowing environment variables from the shell to the JRuby 
container.  Specifically, I'd like to hear of other use cases that a 
config-file driven approach like the one described in the initial post on 
this thread would not satisfy.

Thanks again!

--- Jeremy

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/a2f499fa-5f39-40eb-ab1c-d523a445391e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to