NAPALM opengear driver does not implement force_no_enable

[tynany]

Description of Issue/Question

Commit 638af2d#diff-42f76fa4e7c3a361b0ebdd6daa24796e has broken NAPALM drivers that use _netmiko_open and do not implement force_no_enable. I will submit an MR shortly with a fix.

Did you follow the steps from https://github.com/napalm-automation/napalm#faq

(Place an x between the square brackets where applicable)

• Yes
• [] No

Setup

napalm version

(Paste verbatim output from pip freeze | grep napalm between quotes below)

napalm==3.0.1

Network operating system version

N/A

Steps to Reproduce the Issue

1. Run a NAPALM driver that does not implement the force_no_enable method.

Error Traceback

'$insertNAPALMDriveName' object has no attribute 'force_no_enable'

Example

Example using the OpenGear driver:

network_driver = get_network_driver("opengear")
device = network_driver(
    hostname='device',
    username='user',
    password='pass',
    timeout=30,
)
device.open()

Output:

'OpenGearDriver' object has no attribute 'force_no_enable'

[tynany]

#1240

[ktbyers]

See comments I put in the PR about changing PR to a try/except.

[ktbyers]

I corrected my initial comment here where I was going to advocate correcting this in the opengear driver. I am okay with correcting this in core napalm as long as it is implemented as a graceful handling of the attribute error.

[tynany]

OpenGear is just an example. I took a quick look at all drivers in https://github.com/napalm-automation-community and the below drivers currently suffer from the same issue (i.e. the driver uses _netmiko_open but does not implement force_no_enable).

https://github.com/napalm-automation-community/napalm-huawei-vrp
https://github.com/napalm-automation-community/napalm-onyx
https://github.com/napalm-automation-community/napalm-ciena-saos
https://github.com/napalm-automation-community/napalm-ftos

Actually, no drivers in https://github.com/napalm-automation-community implement force_no_enable, but most call ConnectHandler (from netmiko) directly rather than use _netmiko_open. Perhaps this is the preferred way?

[ktbyers]

It is up to all the community drivers to pin to a specific version of napalm and update them across time as changes are made in napalm.

Using _netmiko_open is likely the preferred solution (as I think that would automatically/properly handle all of Netmiko's arguments getting passed including future arguments).

But the AttributeError and try/except will at least cause them not to break (as the force_no_enable is a very optional behavior).