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_errors.yml#L17
> 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.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.org