-
Notifications
You must be signed in to change notification settings - Fork 158
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 ISSU error for SRX #331
Comments
Did anyone ever resolve this? |
@prime001 - We now support single-RE ISSU. |
I hit the same issue today as I tried to ISSU upgrade a SRX345 cluster. I assume, I have quite recent modules installed (please check below python and ansible module versions). Current running Junos: 18.4R3 I did set the traceoptions as advised at the earlier post and it stopped on VC information collection: May 18 14:41:32 [NETCONF] - [62457] Incoming: <nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:1468ae56-3e79-42ca-bd69-8079b22e69b7"></nc:rpc>]]>]]> BTW: the previous RPC call was - checking REs May 18 14:41:30 [NETCONF] - [62457] Incoming: <nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:7ef9f35b-d281-4de1-9cc7-187ab8ca5186"></nc:rpc>]]>]]> also showing information (serial numbers, fpc etc etc) for both SRX cluster nodes as expected. $ ansible-galaxy collection list ~/.ansible/collections/ansible_collections ansible.netcommon 2.0.2 $ python3 -m pip list ansible 3.3.0 |
I digged deeper in and it seems, the issue is close to here if I check my facts gotten from the SRX Cluster, there is no element 'localre' included out of curiosity, I changed the localre to master and installation starts (kwargs: {"no-sync" : true ) is set as it's a ICU style ISSU on my 345s) is there an issue in facts which causing a missing 'localre'? file show /etc/hosts.junos | match localre gives the expected result btw |
Hi @mersl @prime001 @stuartianbrown Thanks |
Encountering exactly the same issue when using Have there been any solutions or workarounds identified? Alternatively, I managed to perform the upgrade using the following task. However, it requires some adjustment as the RPC never receives a response, leading to eventual timeout. To address this, consider using ignore_errors: true in conjunction with a default timeout.
My next objective is to retrieve the upgrade status for both nodes and present it to the user. |
When attempting an ISSU using the module juniper_junos_software on an SRX550 an error is thrown for the number of routing engines:
However, running the command on the device itself works:
request system software in-service-upgrade junos-srxsme-12.3X48-D50.6-domestic.tgz no-sync
The playbook I'm using is:
The text was updated successfully, but these errors were encountered: