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
On Mon, Aug 8, 2022 at 7:40 AM Richard Megginson <rmegg...@redhat.com>
wrote:
> On Mon, Aug 8, 2022 at 7:28 AM Matt Martz <m...@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 . . .
>
>
>>
>> On Fri, Aug 5, 2022 at 4:43 PM Richard Megginson <rmegg...@redhat.com>
>> wrote:
>>
>>> 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
>>>
>>> On Fri, Aug 5, 2022 at 2:59 PM 'Felix Fontein' via Ansible Development <
>>> ansible-devel@googlegroups.com> wrote:
>>>
>>>> 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
>>>>
>>>>
>>>>
>>>> On Fri, 5 Aug 2022 13:07:29 -0600
>>>> Richard Megginson <rmegg...@redhat.com> wrote:
>>>>
>>>> > 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.
>>>> >
>>>>
>>>> --
>>>> 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-devel+unsubscr...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/ansible-devel/20220805225937.4886bb30%40rovaniemi
>>>> .
>>>>
>>>> --
>>> 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-devel+unsubscr...@googlegroups.com.
>>> 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
>>> <https://groups.google.com/d/msgid/ansible-devel/CALF5A-KMa%2BVdafDXY5n_0wbq_z_-0tSCmGWyx%2BFzFAek%2B3pk%3DQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>>
>> --
>> Matt Martz
>> @sivel
>> sivel.net
>>
>
--
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-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-devel/CALF5A-Kat4RnbixXVHRPoMC%3Duv4ODU7i9hEuY5TZpP%2B17Qi98w%40mail.gmail.com.
