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 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....
> > > _______________________________________________ > 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....