Set commands now failing on junos_install_config

[crosson]

In previous versions of junos_install_config this style of playbook would succeed. This playbook running against an vsrx in eve-ng.

---
- name: Juniper New Out of Box
  hosts: srx
  gather_facts: false
  connection: local

  tasks:
    
  - junos_install_config:
      file: "~/local_ansible/config.set"
      mode: telnet
      user: root
      port: 32781
      host: 10.0.254.1

This now fails under an updated version with the following.
The full traceback is:

Traceback (most recent call last):
  File "/tmp/ansible_8olY8M/ansible_module_junos_install_config.py", line 1127, in <module>
    main()
  File "/tmp/ansible_8olY8M/ansible_module_junos_install_config.py", line 750, in main
    config_format_choices = juniper_junos_common.CONFIG_FORMAT_CHOICES
AttributeError: 'NoneType' object has no attribute 'CONFIG_FORMAT_CHOICES'

fatal: [vsrx]: FAILED! => {
    "changed": false, 
    "failed": true, 
    "module_stderr": "Traceback (most recent call last):\n  File \"/tmp/ansible_8olY8M/ansible_module_junos_install_config.py\", line 1127, in <module>\n    main()\n  File \"/tmp/ansible_8olY8M/ansible_module_junos_install_config.py\", line 750, in main\n    config_format_choices = juniper_junos_common.CONFIG_FORMAT_CHOICES\nAttributeError: 'NoneType' object has no attribute 'CONFIG_FORMAT_CHOICES'\n", 
    "module_stdout": "", 
    "msg": "MODULE FAILURE", 
    "rc": 0
}

Reading the juniper_junos_config.py file shows updates in what arguments are expected. I have tried interpreting this and changed the playbook as:

  - junos_install_config:
      load: "override"
      src: "config.set"
      format: "set"
      mode: 'telnet'
      user: root
      port: 32781
      host: 10.0.254.1

Yet the same error persists. It would be nice to get some direction this. Thanks team!

[stacywsmith]

@crosson Thanks for reporting this issue.

There have been some changes to the arguments and values that this module accepts, and the module has been renamed from junos_install_config to juniper_junos_config.

However, the old module name is still an alias, and all old arguments and values should still be accepted. The goal is 100% backwards compatibility with the 1.4.3 release of these modules. So, if you have a task that was previously working and now produces an error I definitely consider that to be a bug. You shouldn't have to rewrite your task.

I will investigate this issue in more detail tomorrow and get back to you with my analysis.

[stacywsmith]

@crosson

I'm sorry I didn't notice this earlier. This appears to be an installation issue with the new modules. The new modules use a library of shared code which doesn't appear to be installed on your machine.

Unfortunately, I believe this is likely an issue with the ansible-galaxy command. It doesn't handle upgrades cleanly. Please uninstall the modules, and then install cleanly with:

sudo ansible-galaxy remove Juniper.junos
sudo ansible-galaxy install git+https://github.com/Juniper/ansible-junos-stdlib.git,,Juniper.junos

Once this is done, you can confirm that the shared library of code exists by checking for the following file:

<roles_dir>/Juniper.junos/module_utils/juniper_junos_common.py

Note: <roles_dir> is usually /etc/ansible/roles could be different on your machine.

I successfully used the following playbook successfully when trying to replicate your issue:

---
- name: 'Replicate issue #308'
  hosts: junos-all
  connection: local
  gather_facts: no
  roles:
    - Juniper.junos

  tasks:
    - name: 'Replicate issue #308'
      junos_install_config:
        file: "./config.set"
        host: "{{ jaccess.console_ts }}"
        port: "{{ jaccess.console_port }}"
        mode: telnet
        user: root
      register: response
    - name: 'Print result'
      debug:
        var: response

If you wish to update to the new module name and argument syntax, you can also use this equivalent playbook:

---
- name: 'Replicate issue #308'
  hosts: junos-all
  connection: local
  gather_facts: no
  roles:
    - Juniper.junos

  tasks:
    - name: 'Replicate issue #308'
      juniper_junos_config:
        load: 'set'
        src: './config.set'
        host: '{{ jaccess.console_ts }}'
        port: '{{ jaccess.console_port }}'
        mode: telnet
        user: root
      register: response
    - name: 'Print result'
      debug:
        var: response

If you still have issues after cleanly installing the modules, please provide the version of Ansible you are using, and the version of PyEZ you are using.

[crosson]

Let me give your changes a try. I actually didn't use galaxy but just cloned this repository locally then made sure the library was in my ANSIBLE_LIBRARY or just used the --module-path argument. I find the ansible ecosystem very confusing and scattered so I haven't even begun to use galaxy yet(Maybe I Should be).

Thanks so much for the help! I'll let you know shortly if your playbook example solves my problem.

[stacywsmith]

With the addition of new features and shared code, setting ANSIBLE_LIBRARY or specifying --module-path is no longer sufficient to use these modules.

You may, however, still use the modules from a clone of the repository if you follow these steps:

1. Create a Juniper.junos link in your roles_path which points to the ansible-junos-stdlib directory of your cloned repository. i.e.

user@h0:/etc/ansible/roles$ pwd
/etc/ansible/roles
user@h0:/etc/ansible/roles$ ls -la
total 12
drwxr-xr-x 2 root root 4096 Nov 29 14:39 .
drwxr-xr-x 3 root root 4096 Oct  9 12:58 ..
lrwxrwxrwx 1 root root   77 Nov 29 14:39 Juniper.junos -> /home/user/Automation/Projects/Ansible/Repos/stacywsmith/ansible-junos-stdlib

Note: By default, the roles_path is /etc/ansible/roles, but it may be overridden using the roles_path configuration file directive.

2. Make sure to include the Juniper.junos role in your playbook. The start of your play might look something like this:

---
- name: 'Replicate issue #308'
  hosts: junos-all
  connection: local
  gather_facts: no
  roles:
    - Juniper.junos

[crosson]

hi Stacywsmith. I haven't had a chance to test this yet but you sound confident enough. We can close this if you like. I'll need to discuss with my team on galaxy adoption. Seems it would be easier to go that route. In the mean time I can use the workaround you mentioned or use an older version of the module.

[achhabr1]

I am facing the same issue. I have opened up a new bug on this.