Guidance about Jinja variable typing?

[Richard Megginson]

The system roles team has had two issues reported related to variables having different types in Jinja templates:

https://github.com/linux-system-roles/timesync/pull/154

https://github.com/willshersystems/ansible-sshd/issues/188

Both issues appear to be related to some interaction between Jinja 3.0 and ansible-core 2.1x

My question is: what should we do about this in the system roles?  Do we really have to go through all of our Jinja template code and ensure variables are "cast" to their correct type?  Do we have to add requirements.txt, bindep, etc. to ensure that only the correct combinations of ansible-core and Jinja are used?

Both of these solutions seem wrong to me, unless we have been using variables incorrectly in Jinja for years now, and we really should have been "casting" the types all along.

[Felix Fontein]

Hi,

there have been some changes when macros are used in templates. I filed
an issue for this some time ago:
https://github.com/ansible/ansible/issues/78141 Some of the changes
were not intentional and fixed in
https://github.com/ansible/ansible/commit/2aa3cc9e40f46aa9071060052a68c2e82605a9e4
(should be in the next 2.13.x release), while others are intentional
(due to changes how Jinja2 handles native types); the comments in the
issue explain some of the things that happen. Maybe this helps a bit.

Cheers,
Felix

[Richard Megginson]

Thanks.  Yes, this explains the sshd issue.

But the timesync role issue does not involve macros: https://github.com/linux-system-roles/timesync/pull/154/files

```

- {% if timesync_step_threshold != 0.0 %}

+ {% if timesync_step_threshold|float != 0.0 %}

```

That is - for some reason the variable `timesync_step_threshold` stops being a `float` inside the Jinja2 code block - and this only happens with certain combinations of ansible-core + jinja2

--
You received this message because you are subscribed to the Google Groups "Ansible Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-deve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-devel/20220805225937.4886bb30%40rovaniemi.

[Matt Martz]

I think I'd need more evidence and context about how the role is being run, and if/how the user is specifying that value.  

Regardless, the change is safe, and sane.  It probably makes sense to cast them, especially if a caller was to specify that value as an int, since it's just a default users can override.  Or if they were to supply `-e timesync_step_threshold=1.0` from the CLI it would become a string.

There are many ways in which a user tries to specify a value and it results in a string, such as `{{ previsouly_a_float }}` will become a string if done as a module argument to something like `set_fact`.  Unless `jinja2_native` is enabled.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-devel/CALF5A-KMa%2BVdafDXY5n_0wbq_z_-0tSCmGWyx%2BFzFAek%2B3pk%3DQ%40mail.gmail.com.

--

Matt Martz
@sivel
sivel.net

[Richard Megginson]

On Mon, Aug 8, 2022 at 7:28 AM Matt Martz <ma...@sivel.net> wrote:

I think I'd need more evidence and context about how the role is being run, and if/how the user is specifying that value.  

Regardless, the change is safe, and sane.  It probably makes sense to cast them, especially if a caller was to specify that value as an int, since it's just a default users can override.  Or if they were to supply `-e timesync_step_threshold=1.0` from the CLI it would become a string.

 

There are many ways in which a user tries to specify a value and it results in a string, such as `{{ previsouly_a_float }}` will become a string if done as a module argument to something like `set_fact`.  Unless `jinja2_native` is enabled.

Which to me implies that, in template code (macros or otherwise), we should _always_ cast anything which is a float or an int, because we can never be sure how the value was input.

Looks like another item for the recommended practices list - https://github.com/redhat-cop/automation-good-practices/blob/main/coding_style/README.adoc#yaml-and-jinja2-syntax

And I'm going to investigate if there is a way to scan the system roles template code for VAR OP float_or_int_value so I can cast all of it . . .

 

[Richard Megginson]

New addition to recommended practices: https://github.com/redhat-cop/automation-good-practices/pull/77

Script to check for usage of public api variables in roles in numeric operations in Jinja templates: https://github.com/linux-system-roles/auto-maintenance/pull/181