juniper_junos_config returns "check_mode not supported" when attempting to run ansible-playbook --check

[itsgc]

Good Morning,

We have a mostly juniper fleet, with 100% ansible coverage on access switches and various degree of coverage on the Layer 3 gear. We are running version 1.4.2 of ansible-junos-stdlib.

Currently, we tipically run ansible in check_mode first, validate the diff that gets produced and if deemed acceptable, the neteng re-runs ansible without check_mode to deploy the change and commit it to running config.

I ran into a particularly troublesome issue for us with regards to check_mode after trying to upgrade to 2.0.2.

Upgrading the lib to 2.0.2 yields errors about check_mode not being supported by juniper_junos_config.

Updating our playbook to use the new module arguments does not change the result.

Only forcibly disabling check_mode for the task and applying some jinja2 magic to replicate the old check_mode behavior obtains the intended workflow but we don't see this as a viable alternative.

I was hoping to confirm if check_mode is intentionally unsupported or this might be a bug or maybe a misconfiguration on my part?

Thanks for any help or insight you might provide.

Please find the details of the issue attached here:

Our Current Setup that works as intended:
Ansible 2.3.1.0
ansible-junos-stdlib 1.4.2

My test environment:
Ansible 2.3.1.0
ansible-junos-stdlib 2.0.2

Command line used to launch ansible:
ansible-playbook -i prod.hosts site.yml -e user=myusername --check -f25 --ask-vault-pass --limit DEVICE

Relevant snippet of our current playbook (functional with 1.4.2):
playbook_snippet_1.4.2.txt

Output of the task:
TASK [Load the compiled configuration via "load replace"]
*************************************************************
changed: [DEVICE] => {"changed": true, "file": "PATH/compiled/DEVICE/device.conf"}

Upgrading ansible-junos-stdlib to 2.0.2 without changing the playbook or anything else yields:

TASK [Load the compiled configuration via "load replace"] *************************************************************
skipping: [DEVICE] => {"changed": false, "msg": "remote module (junos_install_config) does not support check mode", "skipped": true}

Revised playbook using 2.0.2. (non functional) - this uses "modern" module names and arguments however it does not change the end result:
playbook_snippet_2.0.2.txt

Output:
TASK [Load the compiled configuration via "load replace"] *************************************************************
skipping: [DEVICE] => {"changed": false, "msg": "remote module (juniper_junos_config) does not support check mode", "skipped": true}

I find this puzzling because this variable seems to suggest check_mode should work:
roles/Juniper.junos/library/juniper_junos_config.py:893: supports_check_mode=True

The only way i could get the same behavior as "real" check_mode is by doing this:
playbook_snipper_2.0.2_fake_check_mode.txt

With output:
TASK [Load the compiled configuration via "load replace"] *************************************************************
changed: [DEVICE] => {"changed": true, "failed": false, "file": "compiled/DEVICE/DEVICE.conf", "msg": "Configuration has been: opened, loaded, checked, diffed, closed."}

[stacywsmith]

I would consider this a bug. Check mode should work.
However, I'm unsure if it's a bug in the module, or a bug in Ansible.

[itsgc]

the same ansible version (2.3.1.0) works as intended with the older library version. Our whole setup is in git so im happy to branch out and do tests. Is there a version of ansible you would like me to try instead of 2.3.1.0? Thanks for looking into this!

[stacywsmith]

Does a simple non-check mode task using juniper_junos_facts succeed for you?
Are you using virtualenv or is python installed in a location other than /usr/bin/python?
Are you installing the modules via some method other than ansible-galaxy?

The message that remote module (junos_install_config) does not support check mode is coming from Ansible. Since the only thing the module should have to do to indicate it supports check mode is set supports_check_mode=True as done here, I'm at a loss.

Sorry, I don't have any more info and I'm not sure what version of Ansible to suggest. Since these modules are no longer my "day job" I'm afraid I can't look into it deeper. Hopefully others can help. I just wanted to make it clear that check mode should have worked.

[itsgc]

Hello, i see. Thanks for your time anyway :) For future reference here are the answers to the questions asked above:

• we are using virtual-envs
• module is placed manually in ANSIBLE_ROOT/roles/Juniper.junos
• running a non-check mode version works as intended

I might try running the same setup in a docker container, removing venvs out of the equation and installing from galaxy to see if it changes anything.

Considering we are customers, i however might try the JTAC way since this is pretty much mission critical for us and there are good benefits into 2.0.2. that we currently can't use because of this.

[stacywsmith]

Just to be clear, I am no longer with Juniper. There are still Juniper people supporting these modules. I just suspect they are all sleeping at the moment. ;-)

If you are using virtualenv. Please take a look at ALL of the thread in #322. I suspect that may resolve your issue. You may also want to read all of the thread in #308. Hope that helps.

[itsgc]

I see! Many thanks @stacywsmith (and good luck in your future endeavors!)

I just spun up a new docker container of ubuntu:rolling
Fresh install of ansible-2.3.1.0 from pip [and 2.4.2.0 as well in a different test]
Fresh install of ansible-junos-stdlib 2.0.2 from ansible-galaxy
Python in /usr/bin/python and no virtualenv whatsoever, all packages systemwide.

Exact same issue occurs with both the old-style playbook and the revised version.

EDIT: Attaching output of pip freeze to help with pinpointing which versions i am experiencing this with
pipfreeze.txt

[stacywsmith]

Bummer. I really expected that would fix the issue.

[itsgc]

It was worth a try! i'll let this sit so that some more eyes get a chance to take a look 👍 thanks again!

[vnitinv]

@itsgc we are looking into this. Will get back to you shortly.

[itsgc]

Thanks @vnitinv ! happy to provide anything you need for context. Best

[vnitinv]

@itsgc I got the issue cornered. Would you like to test the fix?

add a line supports_check_mode=True,
after
https://github.com/Juniper/ansible-junos-stdlib/blob/master/library/juniper_junos_config.py#L771
similar to
https://github.com/Juniper/ansible-junos-stdlib/blob/master/library/juniper_junos_config.py#L893

[stacywsmith]

Interesting. That's a good discovery Nitin! Of course that means you'll need to do the same for all of the other modules which support check mode.

[vnitinv]

@stacywsmith we also need to look for other similar parameters which user can pass, say --diff.
Will check if the function import_juniper_junos_common can be modified to be very generic.

[itsgc]

@vnitinv i was out of office yesterday but i'll give it a go today.Many many thanks! will let you know if this fixes it.

[itsgc]

@vnitinv hello Nitin! I can confirm the fix works. when running ansible-playbook -i inventory.file --ask-vault-pass --check --limit DEVICE it works as expected.

It does:

1. connects to the device
2. load the change with load replace
3. performs a commit check
4. does not performs an actual commit
5. fetches a diff back to the ansible host

This is the playbook task i have used to test:

  - name: Load the compiled configuration via "load replace"
    juniper_junos_config:
      timeout=960
      load="replace"
      src=compiled/{{ inventory_hostname }}/{{ inventory_hostname }}.conf
      diffs_file=diffs/{{ inventory_hostname }}.diff
    when: user is defined and configure_interfaces_with_ansible is defined and ll
oad_override is not defined
    tags:
        - deploy

many thanks for your help!