Open ichilton opened 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?
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.
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.
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)Network operating system version
(Paste verbatim output from
show version
- or equivalent - between quotes below)Steps to Reproduce the Issue
Proof the connect is not active until
device.open()
: