Hi Lee, Thanks for answering quickly, I have been worried about this issue all day!
I will reply inline: On 23/05/2025 19:37, Lee Garrett wrote:
I can reproduce the issue, and it's good that you've filed a bug upstream to discuss the options forward there. After all, it's not a final release yet, and now is the time to convince upstream to turn a fatal error into a deprecation warning instead.
I really hope they do that. I fail to understand how they can introduce this kind of breaking changes without any deprecation period!
However, I don't quite understand the use case you have. I never have code in the host_vars/group_vars config. Can you show me some real life examples? I'm willing to take a look to see if we can upgrade those without much hassle. If that fails, upstream might have some ideas that don't involve complete rewrites.
I have tons of code in host/group vars, this allows me keep a separation between reusable generic code (in roles), reusable but opinionated integration code (in playbooks/group vars), and deployment-specific integration code (in inventory/*_vars). Most of the time I am able to solve this using just filters, but Jinja2 expressions are too limited to replace a procedural language, so I occasionally need to resort to hacks like the example I wrote before. I am not proud of that code, but after 10 years of fighting Ansible, it is the best I could find. A very basic example that I could not replace without writing single-user python filters: applying some string formatting to each item in a list. https://github.com/Tina-pm/ansible-playbooks/blob/main/playbooks/group_vars/all/postgresql.yaml#L20C1-L26C15 postgresql_pg_hba_conf__01_trusted_networks: |- {% set result = [] %} {% for net in trusted_networks %} {% set _ = result.append( 'host all all %s %s' % (net, postgresql_default_auth_method)) %} {% endfor %} {{ result }} Some more complex examples: https://github.com/Tina-pm/ansible-roles/blob/v2/roles/simple_bind/vars/main.yaml#L73 https://github.com/Tina-pm/ansible-playbooks/blob/main/playbooks/group_vars/all/simple_bind.yaml#L114
I've heard some other people having some minor breakage, and myself too, but nothing extraordinary. Because of data tagging it's possible to eliminate a whole class of security bugs (namely, double templating issues, and a few other things), and as such I believe it's best to have trixie over the release cycle, especially with the security support up until LTS in mind.
I understand that it is a desirable feature, but this change landed in the repo on the day or their own freeze (just over a month ago), and not many people would have noticed it yet, because usually you don't run your critical code on a pre-release. As much as I like to have recent versions of packages included in the stable release, I think it is a really bad idea to ship trixie with an unreleased and untested new major release. I wouldn't mind if there was an ansible-core-2.18 package, but this gives no option.
Also, if you don't want to handle fixing your playbooks for now, installing 2.18 with pip is also an option.
As a temporary workaround, sure. But I don't think it is a sensible option for Trixie users for the next 2 years. Thanks for reading. -- Martina Ferrari
