I just implemented the ability to pass arbitrary environments to any
task. Currently there is no support to set this for an entire *play*
though that's quite easy to do
and then we can just merge the hashes together (probably coming soon).
Anyway, the usefulness for this is as follows.
Suppose you have packages in an internal company repo and you have
packages in an external repo that you have to go through a proxy to
get through.
For one, you have to set http_proxy. For another, you do not. How
do you do this with ansible?
Relying on the user's shell environment is a gross hack, and you don't
want to HAVE to use the shell module either.
Ideally you should just be able to use yum and apt and pass along
whatever environment variables you want.
So, that's what I've enabled. It works for every single client side
module (it has no meaning for server side modules at this time, but it
won't yell at you if you try).
The example shown uses "vars", but I think this would be super ideal
to put in things like "group_vars/your_location_group" and so on, such
that all systems in the same
group get the same environment variables. Remember to engage
environment on the tasks that need them -- it is not automatically
assigned to all hosts.
Check out the example below -- comments welcome -- and it's already
available in the tree:
I just implemented the ability to pass arbitrary environments to any
task.
...
Suppose you have packages in an internal company repo and you have
packages in an external repo that you have to go through a proxy to
get through.
For one, you have to set http_proxy. For another, you do not. How
do you do this with ansible?
Ideally you should just be able to use yum and apt and pass along
whatever environment variables you want.
I am fairly new to ansible, and this is one of the first issues I ran into, so I was about to ask. Perfect timing
One sublety though: we already populate a local config file of shell-sourceable vars on each client with this proxy info, via other automation. So that's read by existing scripts that setup the shell environment before calling yum.
Would it be possible to have this option as well (source specific client config file into environment as an option to each module)? If it's already possible, excuse my ignorance ...
I realize this brings up shell vs. non-shell modules, but I'm not sure how this is implemented.
I would much rather have the environment be explicit from the tool
than rely of pushing via a shell source file.
Obviously if you want to execute a source statement or a subshell with
the shell module that's fine, but we're not going to make that easier.
It's much better if we model the high level concept than the low level
concept, and a systems management tool *really* shouldn't depend on
the user setup
to decide how it is going to manage a machine -- it's definitions of
that should be absolute, so it's more reliable that way.
