Open shalomb opened 7 years ago
@shalomb
Not sure if this is a bug or an enhancement, but it seems reasonable to support using template variables within settings
.
Thanks for opening this issue!
@chouseknecht - It's a real inconvenience - without being able to control the https?_proxy
envvars for the conductor nothing can be downloaded in environments where you are forced to use a http/https proxy to get out to the net - and ansible-container
will just sit there for hours doing nothing. :|
I believe I have a workaround for now by doing this a bit indirectly.
$ less container.yml
...
settings:
conductor:
environment: '{{ proxy_env }}'
...
and proxy_env
set in a --vars-file
like this
proxy_env:
- http_proxy='http://proxy:3128/'
- https_proxy='http://proxy:3128/'
- ftp_proxy='http://proxy:3128/'
- no_proxy='localhost,127.0.0.1,localaddress,.localdomain.com,169.254.169.254'
Edit: scratch the above - discovered that I had been using a working cached conductor image - looks it is not possible to use jinja at all here.
ISSUE TYPE
container.yml
OS / ENVIRONMENT
SUMMARY
STEPS TO REPRODUCE
The
settings.conductor.environment
if defined as jinja variables (so these can be set and derived from a--vars-files
) will fail with an exception like the followingEXPECTED RESULTS
service.environment
variables can be jinja expressions and are rendered correctly but there is an inconsistency withsettings.conductor.environment
variables - these do not undergo jinja rendering to be populated.In order for these to be defined outside the
container.yml
, variables undersettings.conductor.environment
variables should ideally be processed in exactly the same way thatservices.environment
variables are.ACTUAL RESULTS
Quoting the varialbe doesn't throw an exception but they are not evaluated as jinja expressions.