ansible-collections / ibm_zos_core

Red Hat Ansible Certified Content for IBM Z
78 stars 44 forks source link

[Enhancement] [zos_job_submit][templating] Template does not resolve a variable dependent on another variable #1071

Open fernandofloresg opened 1 year ago

fernandofloresg commented 1 year ago

Is there an existing issue for this?

Are the dependencies a supported version?

IBM Z Open Automation Utilities

v1.2.3

IBM Enterprise Python

v3.9.x

IBM z/OS Ansible core Version

v1.7.0

ansible-version

latest

z/OS version

v2.5

Ansible module

zos_job_submit

Bug description

When using zos_job_submit templating option and having a variable that references another variable and then calling that first variable in a template, the ninja template resolver keeps the variable name as {{ db2_hlq }}.SDSNLOAD whereas it is defined in the template as //JOBLIB DD DISP=SHR,DSN={{ db2_loadlib1 }} and in the vars as db2_loadlib1: "{{ db2_hlq }}.SDSNLOAD"

Link to chat: ( replace with ibm-z slack ) /archives/CSLEJ8VGV/p1701081877027449

Playbook verbosity output.

No response

Ansible configuration.

No response

Contents of the inventory

No response

Contents of group_vars or host_vars

No response

rexemin commented 12 months ago

So Jinja2 by itself doesn't handle nested variables unless you use macros or blocks inside of a template. This behavior comes from Ansible, where the engine takes the trouble to recursively render variables when it detects nesting.

This issue would then deal with an enhancement to the template util to mimic what the Ansible engine does.

stewartfrancis commented 5 days ago

I've fallen over this a bunch of times using the template support in zos_job_submit. It's a bit frustrating that it doesn't behave the same as the rest of Ansible.

Would an option be to support content similarly to zos_copy?

Then users could use the ansible.builtin.template lookup plugin, something like this:

ibm.ibm_zos_core.zos_job_submit:
  content: "{{ lookup('ansible.builtin.template', './my_job.j2') }}"
  ...

I would guess that would benefit from using Ansible's templating engine, so nested variable resolution would just work, as would looking up templates from the built-in search paths, maybe?

We support inline content in the ibm_zos_cics.csd module this way too, for reference (slightly different semantics)