Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

juniper_junos_software : Upgrade fails when using kwargs for re0 or re1 #421

Open
andyjsharp opened this issue Mar 7, 2019 · 1 comment

Comments

@andyjsharp
Copy link

Issue Type

  • Bug Report

Module Name

juniper_junos_software
Juniper.Junos role and Python libraries version

# ansible-galaxy list
- Juniper.junos, 2.1.0

# ansible --version
ansible 2.7.0
  config file = /project/ansible.cfg
  configured module search path = [u'/root/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python2.7/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 2.7.15 (default, Aug 22 2018, 13:24:18) [GCC 6.4.0]
root@b6771e8090a4:/project# juniper_junos_software

# pip freeze
ansible==2.7.0
asn1crypto==0.24.0
backports.ssl-match-hostname==3.5.0.1
bcrypt==3.1.4
beautifulsoup4==4.6.0
bs4==0.0.1
certifi==2017.4.17
cffi==1.11.5
chardet==3.0.4
colorama==0.3.9
configparser==3.5.0
CouchDB==1.2
cryptography==2.3.1
docker==2.4.2
docker-py==1.10.6
docker-pycreds==0.3.0
enum34==1.1.6
future==0.16.0
icdiff==1.9.1
idna==2.5
ipaddress==1.0.22
Jinja2==2.10
jsnapy==1.3.2
junos-eznc==2.2.0
junos-netconify==1.0.2
jxmlease==1.0.1
lxml==3.8.0
MarkupSafe==1.0
ncclient==0.6.3
netaddr==0.7.19
paramiko==2.4.2
pyasn1==0.4.4
pycparser==2.19
PyNaCl==1.3.0
pyparsing==2.2.2
pyserial==3.4
python-gitlab==0.21.2
PyYAML==3.13
requests==2.18.1
scp==0.11.0
selectors2==2.0.1
six==1.10.0
urllib3==1.21.1
websocket-client==0.53.0

OS / Environment

]Junos: 17.3R3.9
Summary

Using kwargs for re0 or re1 to define which RE to upgrade fails to produce the expected results because the version checks fail to understand which RE has been selected via the kwargs. It incorrectly assumes that only the master should be taken into consideration.

Steps to reproduce

Using the following example if RE0 and RE1

RE0 = code version 1.2.0
RE1 = code version 1.2.3
RE0 = backup
RE1 = master

Connection made to the VIP address of the router.

If we attempt to install code version 1.2.3 onto RE0 which does not have the correct version of code installed, we fail to get the software installed because the version check is made to the master (RE1) and because that is running version 1.2.3 we never succeed to upgrade RE0.

- name: "Install on backup re0"
  when: re_backup == 're0'
  juniper_junos_software:
    provider: "{{ credentials }}"
    local_package: "{{ images_dir }}/{{ sw_image }}"
    cleanfs: false
    all_re: false
    reboot: false
    checksum_algorithm: sha1
    validate: true
    version: "{{ sw_version }}"
    logdir: "{{ log_dir }}"
    kwargs:
      re0: true
  register: sw_install_re0_response

Expected results
We would expect that it is possible to upgrade either RE1 or RE0 as instructed.

Actual results

RE0 is not getting upgraded when it should be when RE1 is master and the master has the correct code version installed already.

@chuegel
Copy link

chuegel commented Oct 18, 2021

You can set version: none so that no validation is done

Or you can use the rpc way to upgrade:


- name: "Upgrade JunOS {{ OS_Version }} on Backup RE of {{ inventory_hostname }}"
  when: junos.RE1.mastership_state == "backup" and junos.RE1.status == "OK"
  juniper.device.rpc:
      rpcs:
        - request-package-add
      kwargs:
         reboot: true
         other-routing-engine: true
         no-validate: true
         unlink: false
         package-name: "/var/tmp/{{ OS_Package }}"
      logfile: "{{ LogDir }}/{{inventory_hostname }}-upgrade.txt"
      port: "{{ netconf_port }}"
      timeout: "{{ wait_time }}"
  register: response
  notify:
     - wait_reboot

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants