napalm-automation / napalm

Network Automation and Programmability Abstraction Layer with Multivendor support
Apache License 2.0
2.26k stars 554 forks source link

eos: close() is not closing the connection #1951

Open ichilton opened 1 year ago

ichilton commented 1 year ago

Description of Issue/Question

The connection is still alive and usable after .close() is executed.

It looks like close() is not actually closing the connection?

Setup

napalm version

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

$ pip3 list |grep napalm
napalm                4.1.0

Network operating system version

(Paste verbatim output from show version - or equivalent - between quotes below)

EOS 4.29.3M

Steps to Reproduce the Issue

Proof the connect is not active until device.open():

>>> device.is_alive()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ichilton/.local/lib/python3.9/site-packages/napalm/eos/eos.py", line 258, in is_alive
    if hasattr(self.device.connection, "is_alive") and callable(
AttributeError: 'NoneType' object has no attribute 'connection'
>>> device.open()
>>> device.is_alive()
{'is_alive': True}
>>> device.close()
>>> device.is_alive()
{'is_alive': True}
>>> device.close()
>>> device.is_alive()
{'is_alive': True}
>>> device.close()
>>> device.get_facts()['os_version']
'4.29.3M-31391479.4293M'
bewing commented 1 year ago

This looks like a conscious design decision, due to the fact that no long-lived TCP session is used by the driver when using a non-SSH transport.
https://github.com/napalm-automation/napalm-eos/commit/9fe02f1c8761fdc22cda2473aaf9bfbdc6ff1891

The documentation for is_alive doesn't specifically mention any relationship to the open/close methods, either: https://github.com/napalm-automation/napalm/blob/50ab9f73a2afd8c84c430e5d844e570f28adc917/napalm/base/base.py#L154

Willing to brook debate, but this looks like :wontfix: to me?

ktbyers commented 1 year ago

Yes, I think there is the question of what does is_alive mean for a HTTP based transport (especially if there is no persistence of state, for example, via a cookie).

Probably the most logical thing in a vacuum would be to raise an exception for HTTP based transport since is_alive() is probably not meaningful there.

But then that could make you have different code between HTTP-based devices versus SSH-based devices.

FWIW, is_alive() does not work all that well for SSH either.

arunbalajip commented 9 months ago

In our API, when we get a call - 1) we create a new connection using EOSDriver 2) Run the command 3) Close the connection for every request.

Due to increased volume in our API, we are seeing socket error in the OPEN method in the eapi. File "/napalm/eos/eos.py", line 233, in open raise ConnectionException(str(ce))

if the connection is not closing, will there be a leak in the connection in our API because we are creating new connection every request.