Data Modelling

[Kircheneer]

Between the open type hinting PR #1434 and a short discussion on the Network-to-Code slack server NAPALM channel I got thinking whether it would be best to model the data returned by NAPALM (here) using Pydantic. Currently it is modelled using typing.TypedDict.

Advantages

From my point of view, Pydantic would offer the following advantages:

• Nesting of models with the same base type, as pydantic.BaseModel can be nested (in contrast to typing.TypedDict)
• Run time schema enforcement
  • Useful error messages for driver implementation
  • Ensure at run time that for example a AS number is...
    • ...always represented as an integer rather than a string
    • ...always within the valid range (not negative, not bigger than 4,294,967,295)
• General schema availability for 3rd party apps using NAPALM (say for example Netbox/Nautobot might be able to gain something from having the actual schemas available)
• IDE support (I've worked with FastAPI in the past and the auto completion and type support is quite useful IMO)

The BaseModel class also supports the annotations field, which should allow for a rather easy migration from TypedDict to BaseModel in regards to the model testing code.

>>> from pydantic import BaseModel as m
>>> class M(m):
...   field: str
...
>>> a = M(field="value")
>>> a.__annotations__
{'field': <class 'str'>}

Downsides

As such a change would have to be implemented in every getter method of all the drivers, one of the following things would be needed:

• A compatibility mechanism between "old-style" drivers returning dictionaries from their getters
• Breaking of backwards compatibility at some point (4.0?)

[Kircheneer]

As type hints for NXOS have now landed in this repository it might be worth it having this discussion before going through with type hinting for the other drivers, otherwise that would be duplicated work.

[ktbyers]

I am open to this. @mirceaulinic @bewing -- any thoughts?

It probably would be good to do a small proof-of-concept in some area. Also we would need to work out the compatibility mechanism (I think we would have real difficulty finishing this if there wasn't some compatibility mechanism).

I also think it would (probably) be good to try to get type hinting done before doing this. I think there is a lot of work left to do on that.

[markterantula]

Well, the type hinting was what I was suggesting that I might do :) Having the nxos driver next to it should be good enough for me to tackle this. Maybe even bring the two pieces of code a little more in sync. And with my current gig I have equipment to test it on (that's why I want to use it).

So if that would be welcome, I can have a look at the type hinting stuff. Perhaps I get the hang of it for some other drivers, but that is trickier when testing. I now kinda know how to work with the CI stuff when making a pull request :) that helps

[Kircheneer]

So the NXOS driver is fully type hinted, the other ones are the ones you would want to tackle. If you need anything feel free to reach out, if you're on the NTC slack you can can find "@Kircheneer" there. I would also be happy to give any PR an additional pair of eyes.

[markterantula]

Yes, that is what I meant. My PR is for get_network_instance on nxos_ssh. I'd start with getting nxos type hinted, since I can compare that easier, and do a little testing more easy

[ktbyers]

@markterantula Yeah, definitely feel free to work away on the NXOS-SSH type hints...that would be great.

So have at it.