napalm3 - overall structure and high-level items/goals

[ktbyers]

Definite

• Eliminate Python2 support

Maybe

• Should we change the structural relationship between the napalm-base driver and vendor-specific driver (interface pattern (ABC), adapter pattern).

napalm-automation/napalm-ng#2

• Should we implement type-hinting internally to the napalm code base and mandate Python 3.6 or greater.

[jobec]

• abstraction of all returned data (cfr the LLDP capabilities) where needed. The goal being that users have to bother about the vendor/model as less as possible.
• maybe: return instances of classes instead of dictionaries in dictionaries in dictionaries, ...
• road maps & release cycles
• maybe: extension points/callbacks, for example to influence the driver selection, initial commands sent, custom password things (like getting from a vault).

[luqasz]

• I am for python3.6 or greater. It will be easier to implement async and do yield from
• We can introduce ipaddress for native ip representation, routes, etc.
• Roadmap will clarify things and give a good view of our plans.

[ktbyers]

Merge nxapi-plumbing and pyiosxr directly into NAPALM repository to simplify the maintenance and release process of these two dependencies.

[ktbyers]

Rationalize ping behavior. The ping returned data structure should probably be restructured to be clearer about ping failures. Platforms should be consistent on the ping behavior:

Related:
#946

[ktbyers]

Eliminate get_firewall_policies() method.

[luqasz]

Python 2.7 is EOL by the end of 2020, which is soon. Is there any plan to support 2.7 for some time ?

[ktbyers]

No, I think the plan is to EOL PY2.7 support and move to require >=PY3.6.

@mirceaulinic can chime in if he has different views on this, however (as I haven't really coordinated/discussed it with him).