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
Thanks ,
Harsh
On Sat, May 2, 2020 at 2:57 AM Rich Megginson <rmeggins(a)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_dis...
> 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(a)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(a)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(a)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(a)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.fedorahost...
> > >
> > _______________________________________________
> > systemroles mailing list --
> systemroles(a)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(a)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.fedorahost...
> >
> >
> > _______________________________________________
> > systemroles mailing list -- systemroles(a)lists.fedorahosted.org
> <mailto:systemroles@lists.fedorahosted.org>
> > To unsubscribe send an email to
> systemroles-leave(a)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.fedorahost...
> >
> _______________________________________________
> systemroles mailing list -- systemroles(a)lists.fedorahosted.org
> <mailto:systemroles@lists.fedorahosted.org>
> To unsubscribe send an email to
> systemroles-leave(a)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.fedorahost...
>
>
> _______________________________________________
> systemroles mailing list -- systemroles(a)lists.fedorahosted.org
> To unsubscribe send an email to systemroles-leave(a)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.fedorahost...
>
_______________________________________________
systemroles mailing list -- systemroles(a)lists.fedorahosted.org
To unsubscribe send an email to systemroles-leave(a)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.fedorahost...