Hey everyone, i was trying to modify the test for downing a non existent profile using blocks and rescue ,and I'm getting this error An unhandled exception occurred while templatinga really big JSON object which boils down to this Unexpected templating type error occurred on ({{ network_connections | json_query('[*][ieee802_1x]') | flatten | count > 0 }}): 'NoneType' object is not iterable" which I guess is due to an emty object being returned ? I'm not sure though what exactly this returns or is supposed to return and I'm having some trouble finding a way to fix this . Could someone please help guide me in the right direction ? Any help is appreciated Thanks, Harsh
On 4/30/20 10:37 AM, Harsh Jain 2K18_CO_140 wrote:
Hey everyone, i was trying to modify the test for downing a non existent profile using blocks and rescue ,and I'm getting this error An unhandled exception occurred while templatinga really big JSON object which boils down to this Unexpected templating type error occurred on ({{ network_connections | json_query('[*][ieee802_1x]') | flatten | count > 0 }}): 'NoneType' object is not iterable" which I guess is due to an emty object being returned ? I'm not sure though what exactly this returns or is supposed to return and I'm having some trouble finding a way to fix this . Could someone please help guide me in the right direction ?
Seems like a bug, but hard to say without knowing what your input `network_connections` looks like.
Does it work if you make this change?
diff --git a/defaults/main.yml b/defaults/main.yml index 6b15964..d3977cb 100644 --- a/defaults/main.yml +++ b/defaults/main.yml @@ -22,7 +22,7 @@ network_provider: "{{ network_provider_current }}"
# wpa_supplicant is required if any ieee802_1x connections are defined wpa_supplicant_required: "{{ network_connections | - json_query('[*][ieee802_1x]') | flatten | count > 0 }}" + selectattr('ieee802_1x', 'defined') | list | count > 0 }}" _network_packages_default_802_1x: ["{% if wpa_supplicant_required %}wpa_supplicant{% endif %}"]
Any help is appreciated Thanks, Harsh
systemroles mailing list -- systemroles@lists.fedorahosted.org To unsubscribe send an email to systemroles-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/systemroles@lists.fedorahosted....
Hey Rich , Thanks for the suggestion , it seemed to solve that particular problem, but now it basically wants each variable defined in the defaults to be defined again .For some reason it is unable to use the defaults in the rescue block.I do not know why this was triggered because the connection is non existent and does not have a type defined . Here is how the network connections looks like . network_connections: - name: non_existent type: ethernet state: down persistent_state: absent
This is only happening if I have to check which task failed , if I just use a simple debug msg in the rescue column , it works fine .Would it be okay to just use that, since no other task is in the block , a failure would only come from this task . Currently I'm just using ignore error: yes to ignore the failure of this task Thanks, Harsh
On Thu, Apr 30, 2020 at 10:39 PM Rich Megginson rmeggins@redhat.com wrote:
On 4/30/20 10:37 AM, Harsh Jain 2K18_CO_140 wrote:
Hey everyone, i was trying to modify the test for downing a non existent profile using blocks and rescue ,and I'm getting this error An unhandled exception occurred while templatinga really big JSON
object
which boils down to this Unexpected templating type error occurred on ({{ network_connections | json_query('[*][ieee802_1x]') | flatten | count > 0 }}): 'NoneType' object is not iterable" which I guess is due to an emty object being returned ? I'm not sure though what exactly this returns or is supposed to return and I'm having some trouble finding a way to fix this . Could someone please help guide me in the right direction ?
Seems like a bug, but hard to say without knowing what your input `network_connections` looks like.
Does it work if you make this change?
diff --git a/defaults/main.yml b/defaults/main.yml index 6b15964..d3977cb 100644 --- a/defaults/main.yml +++ b/defaults/main.yml @@ -22,7 +22,7 @@ network_provider: "{{ network_provider_current }}"
# wpa_supplicant is required if any ieee802_1x connections are defined wpa_supplicant_required: "{{ network_connections |
json_query('[*][ieee802_1x]') | flatten | count > 0 }}"
selectattr('ieee802_1x', 'defined') | list | count > 0 }}"Any help is appreciated Thanks, Harsh
systemroles mailing list -- systemroles@lists.fedorahosted.org To unsubscribe send an email to systemroles-leave@lists.fedorahosted.org Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedorahosted.org/archives/list/systemroles@lists.fedorahosted....
systemroles mailing list -- systemroles@lists.fedorahosted.org To unsubscribe send an email to systemroles-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/systemroles@lists.fedorahosted....
On 5/1/20 5:39 AM, Harsh Jain 2K18_CO_140 wrote:
Hey Rich , Thanks for the suggestion , it seemed to solve that particular problem, but now it basically wants each variable defined in the defaults to be defined again .For some reason it is unable to use the defaults in the rescue block.I do not know why this was triggered because the connection is non existent and does not have a type defined . Here is how the network connections looks like . network_connections: - name: non_existent type: ethernet state: down persistent_state: absent
This is only happening if I have to check which task failed , if I just use a simple debug msg in the rescue column , it works fine .Would it be okay to just use that, since no other task is in the block , a failure would only come from this task . Currently I'm just using ignore error: yes to ignore the failure of this task Thanks, Harsh
I'm not sure - do you have your code posted somewhere that I could take a look?
On Thu, Apr 30, 2020 at 10:39 PM Rich Megginson <rmeggins@redhat.com mailto:rmeggins@redhat.com> wrote:
On 4/30/20 10:37 AM, Harsh Jain 2K18_CO_140 wrote: > Hey everyone, > i was trying to modify the test for downing a non existent profile using > blocks and rescue ,and I'm getting this error > An unhandled exception occurred while templatinga really big JSON object > which boils down to this > Unexpected templating type error occurred on ({{ network_connections | > json_query('[*][ieee802_1x]') | flatten | count > 0 }}): 'NoneType' > object is not iterable" > which I guess is due to an emty object being returned ? > I'm not sure though what exactly this returns or is supposed to return > and I'm having some trouble finding a way to fix this . > Could someone please help guide me in the right direction ? Seems like a bug, but hard to say without knowing what your input `network_connections` looks like. Does it work if you make this change? diff --git a/defaults/main.yml b/defaults/main.yml index 6b15964..d3977cb 100644 --- a/defaults/main.yml +++ b/defaults/main.yml @@ -22,7 +22,7 @@ network_provider: "{{ network_provider_current }}" # wpa_supplicant is required if any ieee802_1x connections are defined wpa_supplicant_required: "{{ network_connections | - json_query('[*][ieee802_1x]') | flatten | count > 0 }}" + selectattr('ieee802_1x', 'defined') | list | count > 0 }}" _network_packages_default_802_1x: ["{% if wpa_supplicant_required %}wpa_supplicant{% endif %}"] > Any help is appreciated > Thanks, > Harsh > > _______________________________________________ > systemroles mailing list -- systemroles@lists.fedorahosted.org <mailto:systemroles@lists.fedorahosted.org> > To unsubscribe send an email to systemroles-leave@lists.fedorahosted.org <mailto:systemroles-leave@lists.fedorahosted.org> > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedorahosted.org/archives/list/systemroles@lists.fedorahosted.org > _______________________________________________ systemroles mailing list -- systemroles@lists.fedorahosted.org <mailto:systemroles@lists.fedorahosted.org> To unsubscribe send an email to systemroles-leave@lists.fedorahosted.org <mailto:systemroles-leave@lists.fedorahosted.org> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/systemroles@lists.fedorahosted.org
systemroles mailing list -- systemroles@lists.fedorahosted.org To unsubscribe send an email to systemroles-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/systemroles@lists.fedorahosted....
I'm working on this pr https://github.com/linux-system-roles/network/pull/200 and want to accomplish something like this https://github.com/linux-system-roles/storage/blob/master/tests/tests_disk_e... I'v already posted the version using debug msg in the comments. Thanks, Harsh
On Fri, May 1, 2020 at 7:19 PM Rich Megginson rmeggins@redhat.com wrote:
On 5/1/20 5:39 AM, Harsh Jain 2K18_CO_140 wrote:
Hey Rich , Thanks for the suggestion , it seemed to solve that particular problem, but now it basically wants each variable defined in the defaults to be defined again .For some reason it is unable to use the defaults in the rescue block.I do not know why this was triggered because the connection is non existent and does not have a type defined . Here is how the network connections looks like . network_connections: - name: non_existent type: ethernet state: down persistent_state: absent
This is only happening if I have to check which task failed , if I just use a simple debug msg in the rescue column , it works fine .Would it be okay to just use that, since no other task is in the block , a failure would only come from this task . Currently I'm just using ignore error: yes to ignore the failure of this task Thanks, Harsh
I'm not sure - do you have your code posted somewhere that I could take a look?
On Thu, Apr 30, 2020 at 10:39 PM Rich Megginson <rmeggins@redhat.com mailto:rmeggins@redhat.com> wrote:
On 4/30/20 10:37 AM, Harsh Jain 2K18_CO_140 wrote: > Hey everyone, > i was trying to modify the test for downing a non existent profile using > blocks and rescue ,and I'm getting this error > An unhandled exception occurred while templatinga really big JSON object > which boils down to this > Unexpected templating type error occurred on ({{ network_connections | > json_query('[*][ieee802_1x]') | flatten | count > 0 }}):'NoneType'
> object is not iterable" > which I guess is due to an emty object being returned ? > I'm not sure though what exactly this returns or is supposed to return > and I'm having some trouble finding a way to fix this . > Could someone please help guide me in the right direction ? Seems like a bug, but hard to say without knowing what your input `network_connections` looks like. Does it work if you make this change? diff --git a/defaults/main.yml b/defaults/main.yml index 6b15964..d3977cb 100644 --- a/defaults/main.yml +++ b/defaults/main.yml @@ -22,7 +22,7 @@ network_provider: "{{ network_provider_current }}" # wpa_supplicant is required if any ieee802_1x connections are defined wpa_supplicant_required: "{{ network_connections | - json_query('[*][ieee802_1x]') | flatten | count > 0 }}" + selectattr('ieee802_1x', 'defined') | list | count > 0 }}" _network_packages_default_802_1x: ["{% if wpa_supplicant_required %}wpa_supplicant{% endif %}"] > Any help is appreciated > Thanks, > Harsh > > _______________________________________________ > systemroles mailing list -- systemroles@lists.fedorahosted.org <mailto:systemroles@lists.fedorahosted.org> > To unsubscribe send an email to systemroles-leave@lists.fedorahosted.org <mailto:systemroles-leave@lists.fedorahosted.org> > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives:https://lists.fedorahosted.org/archives/list/systemroles@lists.fedorahosted....
> _______________________________________________ systemroles mailing list -- systemroles@lists.fedorahosted.org <mailto:systemroles@lists.fedorahosted.org> To unsubscribe send an email to systemroles-leave@lists.fedorahosted.org <mailto:systemroles-leave@lists.fedorahosted.org> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:https://lists.fedorahosted.org/archives/list/systemroles@lists.fedorahosted....
systemroles mailing list -- systemroles@lists.fedorahosted.org To unsubscribe send an email to systemroles-leave@lists.fedorahosted.org Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedorahosted.org/archives/list/systemroles@lists.fedorahosted....
systemroles mailing list -- systemroles@lists.fedorahosted.org To unsubscribe send an email to systemroles-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/systemroles@lists.fedorahosted....
On 5/1/20 10:52 AM, Harsh Jain 2K18_CO_140 wrote:
I'm working on this pr https://github.com/linux-system-roles/network/pull/200 and want to accomplish something like this https://github.com/linux-system-roles/storage/blob/master/tests/tests_disk_e... I'v already posted the version using debug msg in the comments.
I think a better way to handle this sort of test is to avoid the use of `ansible_failed_test` altogether. I don't think it is needed. Try this:
- name: Verify that the play fails with the expected error message block: - name: Set down non existent profile include_role: name: linux-system-roles.network vars: network_connections: - name: non_existent type: ethernet state: down persistent_state: absent
- name: This task should never execute set_fact: __network_test_failed: false
rescue: - debug: msg: Success - Task failed - {{ ansible_failed_result }}
always: - assert: that: __network_test_failed | d(true)
I have verified that if the task prior to "name: This task should never execute" succeeds, then __network_test_failed is set correctly, and the `always` block sees the correct value. Note that `ansible_failed_result` can be used to get some information about the failure. Here is what it looks like:
{ "msg": "error: profile specifies interface_name 'non_existent' but no such interface exists", "changed": false, "warnings": [ "[001] <error> #0, state:down persistent_state:absent, 'non_existent': profile specifies interface_name 'non_existent' but no such interface exists" ], "failed": true, "invocation": { "module_args": { "provider": "nm", "connections": [ { "name": "non_existent", "type": "ethernet", "state": "down", "persistent_state": "absent" } ], "ignore_errors": false, "force_state_change": false } }, "_ansible_parsed": true, "_ansible_no_log": false }
So, if you really needed to see what was the exact error message produced, in order to compare it against the expected error message, you could do that e.g.
assert: that: ansible_failed_result.msg is match("error: profile specifies interface_name 'non_existent' but no such interface exists")
If this isn't really acceptable except as a temporary workaround, we can revisit this issue in the system roles code once https://github.com/ansible/ansible/issues/49942 and/or https://github.com/ansible/ansible/issues/57399 are fixed.
Thanks, Harsh
On Fri, May 1, 2020 at 7:19 PM Rich Megginson <rmeggins@redhat.com mailto:rmeggins@redhat.com> wrote:
On 5/1/20 5:39 AM, Harsh Jain 2K18_CO_140 wrote: > Hey Rich , > Thanks for the suggestion , it seemed to solve that particular problem, > but now it basically wants each variable defined in the defaults to be > defined again .For some reason it is unable to use the defaults in the > rescue block.I do not know why this was triggered because the connection > is non existent and does not have a type defined . > Here is how the network connections looks like . > network_connections: > - name: non_existent > type: ethernet > state: down > persistent_state: absent > > This is only happening if I have to check which task failed , if I just > use a simple debug msg in the rescue column , it works fine .Would it be > okay to just use that, since no other task is in the block , a failure > would only come from this task . > Currently I'm just using ignore error: yes to ignore the failure of this > task > Thanks, > Harsh I'm not sure - do you have your code posted somewhere that I could take a look? > > > On Thu, Apr 30, 2020 at 10:39 PM Rich Megginson <rmeggins@redhat.com <mailto:rmeggins@redhat.com> > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>>> wrote: > > On 4/30/20 10:37 AM, Harsh Jain 2K18_CO_140 wrote: > > Hey everyone, > > i was trying to modify the test for downing a non existent > profile using > > blocks and rescue ,and I'm getting this error > > An unhandled exception occurred while templatinga really big > JSON object > > which boils down to this > > Unexpected templating type error occurred on ({{ > network_connections | > > json_query('[*][ieee802_1x]') | flatten | count > 0 }}): 'NoneType' > > object is not iterable" > > which I guess is due to an emty object being returned ? > > I'm not sure though what exactly this returns or is supposed to > return > > and I'm having some trouble finding a way to fix this . > > Could someone please help guide me in the right direction ? > > Seems like a bug, but hard to say without knowing what your input > `network_connections` looks like. > > Does it work if you make this change? > > diff --git a/defaults/main.yml b/defaults/main.yml > index 6b15964..d3977cb 100644 > --- a/defaults/main.yml > +++ b/defaults/main.yml > @@ -22,7 +22,7 @@ network_provider: "{{ network_provider_current }}" > > # wpa_supplicant is required if any ieee802_1x connections are > defined > wpa_supplicant_required: "{{ network_connections | > - json_query('[*][ieee802_1x]') | flatten | count > 0 }}" > + selectattr('ieee802_1x', 'defined') | list | count > 0 }}" > _network_packages_default_802_1x: ["{% if wpa_supplicant_required > %}wpa_supplicant{% endif %}"] > > > > Any help is appreciated > > Thanks, > > Harsh > > > > _______________________________________________ > > systemroles mailing list -- systemroles@lists.fedorahosted.org <mailto:systemroles@lists.fedorahosted.org> > <mailto:systemroles@lists.fedorahosted.org <mailto:systemroles@lists.fedorahosted.org>> > > To unsubscribe send an email to > systemroles-leave@lists.fedorahosted.org <mailto:systemroles-leave@lists.fedorahosted.org> > <mailto:systemroles-leave@lists.fedorahosted.org <mailto:systemroles-leave@lists.fedorahosted.org>> > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedorahosted.org/archives/list/systemroles@lists.fedorahosted.org > > > _______________________________________________ > systemroles mailing list -- systemroles@lists.fedorahosted.org <mailto:systemroles@lists.fedorahosted.org> > <mailto:systemroles@lists.fedorahosted.org <mailto:systemroles@lists.fedorahosted.org>> > To unsubscribe send an email to > systemroles-leave@lists.fedorahosted.org <mailto:systemroles-leave@lists.fedorahosted.org> > <mailto:systemroles-leave@lists.fedorahosted.org <mailto:systemroles-leave@lists.fedorahosted.org>> > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/systemroles@lists.fedorahosted.org > > > _______________________________________________ > systemroles mailing list -- systemroles@lists.fedorahosted.org <mailto:systemroles@lists.fedorahosted.org> > To unsubscribe send an email to systemroles-leave@lists.fedorahosted.org <mailto:systemroles-leave@lists.fedorahosted.org> > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedorahosted.org/archives/list/systemroles@lists.fedorahosted.org > _______________________________________________ systemroles mailing list -- systemroles@lists.fedorahosted.org <mailto:systemroles@lists.fedorahosted.org> To unsubscribe send an email to systemroles-leave@lists.fedorahosted.org <mailto:systemroles-leave@lists.fedorahosted.org> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/systemroles@lists.fedorahosted.org
systemroles mailing list -- systemroles@lists.fedorahosted.org To unsubscribe send an email to systemroles-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/systemroles@lists.fedorahosted....
Hey Rich and Naman, Thanks for the support and help . Unfortunately, I somehow missed this thread and only read this when I had finally finished the rescue using the ansible_failed_test by explicitly defining all the variables ,I had already tried about half of these earlier but had stopped when it said initscripts_variables were undefined which is why I earlier said that it wants each variable in defaults to be defined again . I think the method Rich suggested is way better and I'll use the same . I will put the version using ansible_failed_test in the comments for reference . This was the exact issue that I was having https://github.com/ansible/ansible/issues/49942 Thanks , Harsh
On Sat, May 2, 2020 at 2:57 AM Rich Megginson rmeggins@redhat.com wrote:
On 5/1/20 10:52 AM, Harsh Jain 2K18_CO_140 wrote:
I'm working on this pr https://github.com/linux-system-roles/network/pull/200 and want to accomplish something like this
https://github.com/linux-system-roles/storage/blob/master/tests/tests_disk_e...
I'v already posted the version using debug msg in the comments.
I think a better way to handle this sort of test is to avoid the use of `ansible_failed_test` altogether. I don't think it is needed. Try this:
- name: Verify that the play fails with the expected error message block: - name: Set down non existent profile include_role: name: linux-system-roles.network vars: network_connections: - name: non_existent type: ethernet state: down persistent_state: absent - name: This task should never execute set_fact: __network_test_failed: false rescue: - debug: msg: Success - Task failed - {{ ansible_failed_result }} always: - assert: that: __network_test_failed | d(true)I have verified that if the task prior to "name: This task should never execute" succeeds, then __network_test_failed is set correctly, and the `always` block sees the correct value. Note that `ansible_failed_result` can be used to get some information about the failure. Here is what it looks like:
{ "msg": "error: profile specifies interface_name 'non_existent' but no such interface exists", "changed": false, "warnings": [ "[001] <error> #0, state:down persistent_state:absent, 'non_existent': profile specifies interface_name 'non_existent' but no such interface exists" ], "failed": true, "invocation": { "module_args": { "provider": "nm", "connections": [ { "name": "non_existent", "type": "ethernet", "state": "down", "persistent_state": "absent" } ], "ignore_errors": false, "force_state_change": false } }, "_ansible_parsed": true, "_ansible_no_log": false }
So, if you really needed to see what was the exact error message produced, in order to compare it against the expected error message, you could do that e.g.
assert: that: ansible_failed_result.msg is match("error: profile specifies interface_name 'non_existent' but no such interface exists")
If this isn't really acceptable except as a temporary workaround, we can revisit this issue in the system roles code once https://github.com/ansible/ansible/issues/49942 and/or https://github.com/ansible/ansible/issues/57399 are fixed.
Thanks, Harsh
On Fri, May 1, 2020 at 7:19 PM Rich Megginson <rmeggins@redhat.com mailto:rmeggins@redhat.com> wrote:
On 5/1/20 5:39 AM, Harsh Jain 2K18_CO_140 wrote: > Hey Rich , > Thanks for the suggestion , it seemed to solve that particular problem, > but now it basically wants each variable defined in the defaults to be > defined again .For some reason it is unable to use the defaults in the > rescue block.I do not know why this was triggered because the connection > is non existent and does not have a type defined . > Here is how the network connections looks like . > network_connections: > - name: non_existent > type: ethernet > state: down > persistent_state: absent > > This is only happening if I have to check which task failed , if I just > use a simple debug msg in the rescue column , it works fine .Would it be > okay to just use that, since no other task is in the block , a failure > would only come from this task . > Currently I'm just using ignore error: yes to ignore the failure of this > task > Thanks, > Harsh I'm not sure - do you have your code posted somewhere that I couldtake
a look? > > > On Thu, Apr 30, 2020 at 10:39 PM Rich Megginson <rmeggins@redhat.com <mailto:rmeggins@redhat.com> > <mailto:rmeggins@redhat.com <mailto:rmeggins@redhat.com>>> wrote: > > On 4/30/20 10:37 AM, Harsh Jain 2K18_CO_140 wrote: > > Hey everyone, > > i was trying to modify the test for downing a non existent > profile using > > blocks and rescue ,and I'm getting this error > > An unhandled exception occurred while templatinga reallybig
> JSON object > > which boils down to this > > Unexpected templating type error occurred on ({{ > network_connections | > > json_query('[*][ieee802_1x]') | flatten | count > 0 }}): 'NoneType' > > object is not iterable" > > which I guess is due to an emty object being returned ? > > I'm not sure though what exactly this returns or is supposed to > return > > and I'm having some trouble finding a way to fix this . > > Could someone please help guide me in the right direction ? > > Seems like a bug, but hard to say without knowing what yourinput
> `network_connections` looks like. > > Does it work if you make this change? > > diff --git a/defaults/main.yml b/defaults/main.yml > index 6b15964..d3977cb 100644 > --- a/defaults/main.yml > +++ b/defaults/main.yml > @@ -22,7 +22,7 @@ network_provider: "{{ network_provider_current }}" > > # wpa_supplicant is required if any ieee802_1x connectionsare
> defined > wpa_supplicant_required: "{{ network_connections | > - json_query('[*][ieee802_1x]') | flatten | count > 0 }}" > + selectattr('ieee802_1x', 'defined') | list | count > 0}}"
> _network_packages_default_802_1x: ["{% if wpa_supplicant_required > %}wpa_supplicant{% endif %}"] > > > > Any help is appreciated > > Thanks, > > Harsh > > > > _______________________________________________ > > systemroles mailing list -- systemroles@lists.fedorahosted.org <mailto:systemroles@lists.fedorahosted.org> > <mailto:systemroles@lists.fedorahosted.org <mailto:systemroles@lists.fedorahosted.org>> > > To unsubscribe send an email to > systemroles-leave@lists.fedorahosted.org <mailto:systemroles-leave@lists.fedorahosted.org> > <mailto:systemroles-leave@lists.fedorahosted.org <mailto:systemroles-leave@lists.fedorahosted.org>> > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: >https://lists.fedorahosted.org/archives/list/systemroles@lists.fedorahosted....
> > > _______________________________________________ > systemroles mailing list -- systemroles@lists.fedorahosted.org <mailto:systemroles@lists.fedorahosted.org> > <mailto:systemroles@lists.fedorahosted.org <mailto:systemroles@lists.fedorahosted.org>> > To unsubscribe send an email to > systemroles-leave@lists.fedorahosted.org <mailto:systemroles-leave@lists.fedorahosted.org> > <mailto:systemroles-leave@lists.fedorahosted.org <mailto:systemroles-leave@lists.fedorahosted.org>> > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: >https://lists.fedorahosted.org/archives/list/systemroles@lists.fedorahosted....
> > > _______________________________________________ > systemroles mailing list -- systemroles@lists.fedorahosted.org <mailto:systemroles@lists.fedorahosted.org> > To unsubscribe send an email to systemroles-leave@lists.fedorahosted.org <mailto:systemroles-leave@lists.fedorahosted.org> > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives:https://lists.fedorahosted.org/archives/list/systemroles@lists.fedorahosted....
> _______________________________________________ systemroles mailing list -- systemroles@lists.fedorahosted.org <mailto:systemroles@lists.fedorahosted.org> To unsubscribe send an email to systemroles-leave@lists.fedorahosted.org <mailto:systemroles-leave@lists.fedorahosted.org> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:https://lists.fedorahosted.org/archives/list/systemroles@lists.fedorahosted....
systemroles mailing list -- systemroles@lists.fedorahosted.org To unsubscribe send an email to systemroles-leave@lists.fedorahosted.org Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedorahosted.org/archives/list/systemroles@lists.fedorahosted....
systemroles mailing list -- systemroles@lists.fedorahosted.org To unsubscribe send an email to systemroles-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/systemroles@lists.fedorahosted....
Hey there, Hope you're doing well!!
Because I did spend a lot of time on this, one thing that I'm very sure of is that, Harsh, you'll have to definitely incorporate some more attributes to combat the failures/ errors that come up, since it's going to be completely dependent on the network scenario found on a particular site.
You'll have to make use of the handlers in many instances, or be it the action that needs to be taken forward when it fails with the help of "failed_when" attribute. Again, it can be a list of all these to make your playbook better for every possible situation like by "any_errors_fatal", "changed_when", etc. Block and rescue are always very crucial for the same and need to be used very appropriately.
Just a piece of advise that I thought to share with you as it can be helpful!
Cheers, Naman
systemroles@lists.fedorahosted.org
-
Harsh Jain -
Harsh Jain 2K18_CO_140
-
Naman Dhingra -
Rich Megginson