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 [email protected].
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.
