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:
environment-variables: {
FOO: $FOO
BAR: $BAR:-val
}
Thanks,
Nan
--
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/fefee74a-7b50-4780-bd02-8e4aaade2a49%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
