11:05 a.m.
Hey @all,
currently I'm seeing weird effects of non-resolvable variables again.
I'm using Debops v1.0.1 with some cherry-picks not related to ferm and
apache2. Using the example playbook from [1] and no specific inventory
variables, I encounter the following error:
TASK [debops.apache : Create conf-available snippets]
***********************************************************************
[WARNING]: Unable to find 'lookup/ferm__fix_dependent_rules.j2' in
expected paths (use -vvvvv to see paths)
failed: [test] (item={'value': True, 'key':
u'local-debops_apache'}) =>
{"ansible_loop_var": "item", "changed": false,
"item": {"key":
"local-debops_apache", "value": true}, "msg":
"AnsibleError: An
unhandled exception occurred while templating '{{ lookup(\"template\",
\"lookup/ferm__fix_dependent_rules.j2\", convert_data=False) | from_json
}}'. Error was a <class 'ansible.errors.AnsibleError'>, original
message: An unhandled exception occurred while running the lookup plugin
'template'. Error was a <class 'ansible.errors.AnsibleError'>,
original
message: the template file lookup/ferm__fix_dependent_rules.j2 could not
be found for the lookup"}
...
As I imagine the problem is as follows:
* In this task the template
ansible-debops/ansible/roles/debops.apache/templates/etc/apache2/conf-available/local-debops_apache.conf.j2
is evaluated which has import-statements for macros
* As the imports are called "with context" Jinja2 tries to pass down the
full variable context and evaluates "ferm__fix_dependent_rules", which
has not been used before
* This obviously fails, because the referenced template could not be located
Do any of you guys have an idea on how to circumvent this error?
Maybe by making sure, that ferm__fix_dependent_rules is used in the ferm
role?
Can I prevent debops.apache from evaluating vars from debops.ferm?
Best regards
Fabian
PS: This might be a double posting, as I didn't see the email yesterday.
Sorry, if it is
[1]
https://docs.debops.org/en/latest/ansible/roles/debops.apache/getting-sta...
[2] http://jinja.pocoo.org/docs/2.10/templates/#import-context-behavior
11:14 a.m.
On Jul 05, Fabian Reiners wrote:
currently I'm seeing weird effects of non-resolvable variables
again.
I'm using Debops v1.0.1 with some cherry-picks not related to ferm and
apache2. Using the example playbook from [1] and no specific inventory
variables, I encounter the following error:
TASK [debops.apache : Create conf-available snippets]
***********************************************************************
[WARNING]: Unable to find 'lookup/ferm__fix_dependent_rules.j2' in
expected paths (use -vvvvv to see paths)
failed: [test] (item={'value': True, 'key':
u'local-debops_apache'}) =>
{"ansible_loop_var": "item", "changed": false,
"item": {"key":
"local-debops_apache", "value": true}, "msg":
"AnsibleError: An
unhandled exception occurred while templating '{{ lookup(\"template\",
\"lookup/ferm__fix_dependent_rules.j2\", convert_data=False) | from_json
}}'. Error was a <class 'ansible.errors.AnsibleError'>, original
message: An unhandled exception occurred while running the lookup plugin
'template'. Error was a <class 'ansible.errors.AnsibleError'>,
original
message: the template file lookup/ferm__fix_dependent_rules.j2 could not
be found for the lookup"}
...
As I imagine the problem is as follows:
* In this task the template
ansible-debops/ansible/roles/debops.apache/templates/etc/apache2/conf-available/local-debops_apache.conf.j2
is evaluated which has import-statements for macros
* As the imports are called "with context" Jinja2 tries to pass down the
full variable context and evaluates "ferm__fix_dependent_rules", which
has not been used before
* This obviously fails, because the referenced template could not be located
Do any of you guys have an idea on how to circumvent this error?
Maybe by making sure, that ferm__fix_dependent_rules is used in the ferm
role?
Can I prevent debops.apache from evaluating vars from debops.ferm?
Hello!
This is a common occurence with Jinja version lower than 2.10. Check which one
you have and upgrade it to at least 2.10, that should fix the issue. Let me
know if that helped.
Cheers,
Maciej
11:29 a.m.
Hey Maciej,
This is a common occurence with Jinja version lower than 2.10. Check
which one
you have and upgrade it to at least 2.10, that should fix the issue. Let me
know if that helped.
I already checked. Installed versions:
ansible==2.8.0
Jinja2==2.10
python version = 2.7.15rc1 (default, Nov 12 2018, 14:31:15) [GCC 7.3.0]
\Fabian
11:41 a.m.
On Jul 05, Fabian Reiners wrote:
> This is a common occurence with Jinja version lower than 2.10.
Check which one
> you have and upgrade it to at least 2.10, that should fix the issue. Let me
> know if that helped.
I already checked. Installed versions:
ansible==2.8.0
Jinja2==2.10
python version = 2.7.15rc1 (default, Nov 12 2018, 14:31:15) [GCC 7.3.0]
Then it's probably due to issues with Jinja and import statements in loops,
ref: https://github.com/pallets/jinja/issues/659. I fixed this in debops.nginx
by removing the import statement from the 'index.html' template:
https://github.com/debops/debops/pull/223. This would also have to be done
with debops.apache role. Any chance you could switch to debops.nginx for now?
It's used much more and therefore more up to date at the moment.
Cheers,
Maciej
12:18 p.m.
Hey Maciej,
Am 05.07.19 um 11:41 schrieb Maciej Delmanowski:
On Jul 05, Fabian Reiners wrote:
>> This is a common occurence with Jinja version lower than 2.10. Check which one
>> you have and upgrade it to at least 2.10, that should fix the issue. Let me
>> know if that helped.
>
> I already checked. Installed versions:
>
> ansible==2.8.0
> Jinja2==2.10
> python version = 2.7.15rc1 (default, Nov 12 2018, 14:31:15) [GCC 7.3.0]
Then it's probably due to issues with Jinja and import statements in loops,
ref: https://github.com/pallets/jinja/issues/659. I fixed this in debops.nginx
by removing the import statement from the 'index.html' template:
https://github.com/debops/debops/pull/223. This would also have to be done
with debops.apache role. Any chance you could switch to debops.nginx for now?
It's used much more and therefore more up to date at the moment.
I just checked and indeed the template renders fine with Jinja2==2.8 and
starts failing with Jinja2==2.9. I am not quite sure so, if it is
exactly the same bug, because I was quick checking the used templates
and I cannot see a template included in a loop.
No worries, I am going to switch over to nginx. Thanks for your time and
effort.
Best regards,
Fabian
1945
days inactive
1945
days old
4 comments
2 participants
participants (2)
-
Fabian Reiners -
Maciej Delmanowski