sw.install(): no-copy argument is not passed further to rpc command

[eleksis]

Description:
We have a large number of EX2300 switches that need to be upgraded. Process is automated with ansible, which underneath uses junos-eznc library.

Because of very low storage capacity on this model, upgrade process fails due to insufficient space with default command that this module produces:
/usr/libexec/ui/package -X update -no-validate /var/tmp/junos-arm-32-18.1R3-S9.1.tgz

If I first copy firmware to device and then run command with no-copy flag, upgrade succeeds:
request system software add no-copy no-validate /var/tmp/junos-arm-32-18.1R3-S9.1.tgz

Although junos_package module (in ansible) and function sw.install() (in junos-eznc) have no-copy argument. It is only used to determine if package should be copied to device or not, but no-copy flag is actually never appended to rpc command.

Expected behavior:
If no-copy argument is set to True, append no-copy flag to rpc command.

File:
jnpr/junos/utils/sw.py

junos-eznc version: any
ansible version: any

[vnitinv]

@eleksis as of now no-copy for PyEZ was used as 'dont copy image its available on device' but for junos no-copy means different.
we need to take look to this parameter. Will discuss with team and get back to you

[eleksis]

@vnitinv You are right. I don't know what exactly no-copy flag does 'behind the scene', but it sure helps when upgrading devices with small flash. Maybe it could even be added permanently like 'no-validate' if it doesn't have any negative effects.

[zerowaitstate]

Did not notice this issue when I put in #994 , but they are related.

[eleksis]

After some additional testing in some cases only no-copy flag is not enough.
According to docs, quote:

Install the Junos OS release software by using the no-copy, unlink, and force options

we will need support for all these flags in order to successfully make upgrade.

[eleksis]

@vnitinv ping

[vnitinv]

@eleksis sw.install supports all the parameters at run-time (it's designed dynamically as many params keep getting added now and then for request package add command). If it's not documented, it will still pick it up and pass it to RPC call.
So give a try with any params you want to use. If you face any issue, let us know.

[eleksis]

@vnitinv Yes, I see sw.install method passes kwargs to pkgadd, but what bothers me is 'no-copy' argument. As it is already used in sw.install method and if i understand correctly there is no way to pass it further to pkgadd. Correct me if i am wrong.

ps. Another thing is, I am not even 100% if I need to pass 'no-copy' flag to 'package add' command. As junos firmware is not open-source it is just black box for us and we are just trying to make upgrade process to work. It would be really helpful if any of junos developers can give an explanation, what this flag actually does behind the scenes.

[crosswordsinpen]

I believe the CLI version of no-copy prevents the process from first moving the file from /var/tmp/ to /var/sw/pkg/

On my most recent install, I saw that I have a file in both folder locations before running a storage cleanup.

[apurvaraghu]

The no-copy argument used in sw.install() method is used within the PyEZ framework to control how the software installation will be handled and not directly passed to underlying pkgadd command in Junos.
The purpose of this flag is to tell PyEz not to copy the software package to the device before the installation process. This is useful if the software is already present on the device and thus avoiding duplication. When no-copy is set to True, PyEz will expect the software to be available on the device and then install it directly from that location without making additional copy.

[crosswordsinpen]

Your point is well taken, and I believe the essence of the discussion among us highlights an inconsistency with Junos OS. Specifically, while 'no-copy' is available as a CLI command, it appears that the SW class within PyEZ does not offer a corresponding method to invoke 'no-copy' functionality directly from the CLI. This discrepancy can lead to confusion and inefficiencies in managing Junos devices programmatically. It would be beneficial for the PyEZ library to address this inconsistency to streamline operations and enhance user experience.