Create napalm-netmiko middlelayer (discussion)

[ktbyers]

Thread from @dbarrosop

if you have the time I'd like to discuss the idea of having a generic napalm-netmiko driver, something to allow instant support to devices that are supported by netmiko

the idea would be to have the minimum required to detect the type of device and run commands and make configuration changes, nothing else

the rest of the functionality should come from napalm-yang and profiles

potentially IOS could go in there as well I guess but only the bits that involve making config changes

the replace operation wouldn't work there (unless IOS)

thoughts?

[ktbyers]

Add @dbarrosop @mirceaulinic

[ktbyers]

@dbarrosop @mirceaulinic The main value I see it that would allow us to share common code between drivers that use Netmiko.

When you say make configuration changes here--I assume you are referring to making configuration changes using the NAPALM config change API?

the idea would be to have the minimum required to detect the type of 
device and run commands and make configuration changes, nothing else

I think we could share code, but implementing the NAPALM Config API would probably have to be in the device specific driver (or worded another way, I think it is going to be really hard to achieve much of the NAPALM Config API in a generic Netmiko driver).

I would also wonder if we should make Paramiko/Netmiko a dependency and push shared code up into NAPALM-base (i.e. I get a bit worried about adding complexity that a third middle-layer would add). But I think you envision more than just sharing common code.

I do think (at a minimum) we should try to come up with a way to share common Netmiko code inside of NAPALM (whether in a middle-layer or in NAPALM-base).

[dbarrosop]

@ktbyers I think it should support for any device:

• open
• close
• load_merge_candidate
• discard
• commit
• cli
• _profile (or similar, something that can populate a profile attribute with a unique id like)

For certain profiles we could maybe implement other methods. The idea is that this should provide the minimum necessary for napalm-yang to work properly as we could do all the heavy lifting for diffs and getters there instead.

[ktbyers]

@dbarrosop

Mapping these to Netmiko

• open (no issue)
• close (no issue)
• load_merge_candidate

Netmiko has no concept of candidate config (in general). It has two config methods send_config_set and send_config_from_file. Both of these go and directly enter configuration commands in config mode. The exception to this being the Netmiko Juniper and Netmiko IOS-XR drivers.

• discard (No discard except possibly Juniper and IOS-XR)
• commit (No commit except Juniper and IOS-XR)

[dbarrosop]

Worst case load_merge_candidate could just be an in memory object. Something you can keep making additions, check the state, discard it or just apply it. As we are not aiming the for in box diff here we don't really have to load the candidate into the device.