-
Notifications
You must be signed in to change notification settings - Fork 153
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
Current implementation doesn't handle multi member stacks where versions of members are inconsistent #613
Comments
Support for software installation on specific members "member_id" of EX-VC
Hi @lukebaldan ,
Thanks & Regards |
Support for software installation on specific members "member_id" of EX-VC
Fix is merged - #617 |
Hi @chidanandpujar. I have tested in my environment and it appears the new code is broken. Even if member_id is not specified, the upgrade no longer completes:
I suspect the rpc does not support the member-id parameter. Interestingly if I omit the member_id parameter to perform an upgrade on all RE's, I still encounter a fail: fatal: [switch1_ex4200]: FAILED! => { |
Hi @lukebaldan Thanks |
Hi @lukebaldan
Thanks |
Hi @lukebaldan , I am able to execute the playbook without any issues .
Thanks |
Hi @chidanandpujar Based on your feedback, i upgraded PyEZ and i am happy to report that initial testing looks good. I am able to successfully upgrade/downgrade individual members without version checking issues. I will continue to test, but i am 95% confident, this feature has been implemented correctly. |
Hi @lukebaldan Thanks |
Issue Type
Module Name
juniper.device.software
juniper.device collection and Python libraries version
OS / Environment
Juniper EX4200 configured with 3 members and following starting versions:
Summary
The existing juniper.device.software module seems to work fine if all members of the switch stack are on the same starting version.
If the current re (Member 0) is on version B and members 1 and 2 are on version A. Attempting an upgrade to version B will fail because of the following lines of code which checks the version of the current RE only.
Ideally the module should be able to upgrade all members of the stack regardless of their current version to the target version.
Steps to reproduce
Expected results
Expect Members 1 and 2 to be upgraded to 12.3R12-S12 to match master / member 0.
Actual results
Instead, debug reveals that current version is the same as targeted and the upgrade is not performed:
ok: [X] => {
"changed": false,
"check_mode": false,
"invocation": {
"module_args": {
"attempts": null,
"baud": null,
"checksum": null,
"checksum_algorithm": "md5",
"checksum_timeout": 300,
"cleanfs_timeout": 300,
"console": null,
"cs_passwd": null,
"cs_user": null,
"force_host": false,
"host": "10.x.x.x",
"huge_tree": false,
"issu": false,
"level": null,
"logdir": null,
"logfile": "/tmp/junosutils/files/logs/x.log",
"mode": null,
"nssu": false,
"passwd": "VALUE_SPECIFIED_IN_NO_LOG_PARAMETER",
"port": 830,
"ssh_config": null,
"ssh_private_key_file": null,
"timeout": 10,
"user": "x",
"validate": false,
"vmhost": false
}
},
"msg": "Current version on 12.3R12-S12: fpc0 same as Targeted version: 12.3R12-S12.\n"
}
The text was updated successfully, but these errors were encountered: