Config.diff() issue with rsp type

[alexandrecorso]

I found a strange behaviour with Ansible, using PyEZ via Junos Module.

ansible            2.10.0
junos-eznc     2.5.3

The module I use with ansible is this one:

juniper_junos_config:
        src: "{{ path_junos_conf }}"
        provider: "{{ credentials }}"
        config_mode: "private"
        load: replace
        ignore_warning: true
        diff: true
        check: true
        commit: false

On some devices - MX (Junos: 18.4R3-S5.4) I got an error on the modulee Config.diff

  File "/Users/acorso/.virtualenvs/ansible/lib/python3.8/site-packages/jnpr/junos/utils/config.py", line 256, in diff
    diff_txt = rsp.find("configuration-output").text

I check the value of rsp (via return f"rsp: {type(rsp)}: {rsp}" on the file https://github.com/Juniper/py-junos-eznc/blob/master/lib/jnpr/junos/utils/config.py, just before the line 256)

"rsp: <class 'bool'>: True"

On https://github.com/Juniper/py-junos-eznc/blob/master/lib/jnpr/junos/utils/config.py I don't see any check about the type like

if not type(rsp) == dict: 
    return None

I'm curious about the type of rsp variable. I should be something like this:

"rsp: <class 'lxml.etree._Element'>: <Element configuration-information at 0x112136680>"

I found this issue only on one device and where there is the no change (no diff)

Alexandre Corso

[alexandrecorso]

I have the issue with Junos: 18.4R3-S5.4

[dangoscomb]

I am having the same issue on 18.4R3-S6.3

rpc.get_configuration(compare="rollback", rollback="0")

returns True for the above version when there are no changes, whereas on older versions it returns an Element with no text value. When there are changes an Element is returned with the text value populated as expected.

Suggest it checks for an Element as you allude to above.

if not type(rsp) == etree._Element:

[rahkumar651991]

The pull request #1093 is not a fix but a workaround added to pass this scenario. This is a bug in junos for certain releases. As I understand, it should be working fine in 18.4R3-S7.
The changes if done in PyEZ as mentioned in above link will let us allow multiple error-scenario as successful-scenario, so is not recommended.

One workaround can be done in playbook by modifying the task as
juniper_junos_config:
src: "{{ path_junos_conf }}"
provider: "{{ credentials }}"
config_mode: "private"
load: replace
ignore_warning: true
diff: false
check: false
commit: false

This task if works with the requirements, then can be used.

[rahkumar651991]

Closing this issue as it is junos bug for certain releases and should work fine for newer releases.
The suggested fix will work for these releases but is a workaround and is not recommended as it will let us allow multiple error-scenario as successful-scenario.

[rahkumar651991]

As discussed in #1093 will keep this open and add a check for error-handling for such scenario.

[rahkumar651991]

closing this based on #1116