Introduce hardware inventory functionality

[jeremystretch]

I'm interested in extending NAPALM to include a method for retrieving hardware information from devices. Currently, only the chassis serial number can be read (via get_facts()). I'd like to add the ability to return the equivalent of show chassis hardware (Junos) or show inventory (IOS). Here's an example CLI output for Junos:

demo> show chassis hardware 
Hardware inventory:
Item             Version  Part number  Serial number     Description
Chassis                                VG371429XXXX      QFX5100-24Q-2P
Pseudo CB 0     
Routing Engine 0          BUILTIN      BUILTIN           QFX Routing Engine
FPC 0            REV 06   650-056263   VG371429XXXX      QFX5100-24Q-2P
  CPU                     BUILTIN      BUILTIN           FPC CPU
  PIC 0                   BUILTIN      BUILTIN           24x 40G-QSFP
    Xcvr 0       2M DAC   740-038623   F786SNG-A         QSFP+-40G-CU1M
    Xcvr 1       7M AOC   740-032986   F8205J4-B         QSFP+-40G-SR4
    Xcvr 2       7M AOC   740-032986   F8205TG-B         QSFP+-40G-SR4
    Xcvr 3       2M DAC   740-038623   F786SNL-A         QSFP+-40G-CU1M
    Xcvr 4       2M DAC   740-038623   F786SNP-A         QSFP+-40G-CU1M
  PIC 1          REV 03   611-049555   RR371408XXXX      QFX-EM-4Q
  PIC 2          REV 03   611-049555   RR371408XXXX      QFX-EM-4Q
Power Supply 0   REV 03   740-044332   1GA1413XXXX       JPSU-650W-AC-AFI
Power Supply 1   REV 03   740-044332   1GA1413XXXX       JPSU-650W-AC-AFI
Fan Tray 0                                               QFX5100 Fan Tray 0, Back to Front Airflow - AFI
Fan Tray 1                                               QFX5100 Fan Tray 1, Back to Front Airflow - AFI

And for IOS:

demo# show inventory 
NAME: "1", DESCR: "WS-C3560X-48"
PID: WS-C3560X-48T-L   , VID: V05  , SN: FDO1720XXXX

NAME: "Power Supply 0", DESCR: "FRU Power Supply"
PID: C3KX-PWR-350WAC   , VID: V03L , SN: LIT1731XXXX

NAME: "Power Supply 1", DESCR: "FRU Power Supply"
PID: C3KX-PWR-350WAC   , VID: V03L , SN: LIT1851XXXX

The proposed method would be read-only, similar to get_environment(). It would return a list of objects, each representing a hardware component. The format of each object will be largely arbitrary, as it would probably not be practical to attempt to standardize among the platforms, but each component would include at least a name, model/part number, and serial number. I'm not too familiar with OpenConfig yet, but I believe this object would correspond to the platform model.

My primary interest in adding this capability is to extend an IPAM/DCIM application I maintain called NetBox. It would be great to replace the custom RPC functionality I've written with NAPALM; I just need to implement the hardware inventory piece. Beyond that, of course, there's inherent value in being able to retrieve a list of all the components installed within a device.

If people think this would be a valuable addition to NAPALM, I'd love to volunteer my time.

[dbarrosop]

This sounds great to me. Give me a few days to investigate which OC models we need and then I can guide you on how to get it done with the OC framework.

[jeremystretch]

@dbarrosop Just checking in. Happy to give this a shot on my own if you can't spare the time.

[dbarrosop]

I haven't forgotten about this :) I am almost done but there is a severe lack of documentation on how to use the framework. If you have the energy you can look at this:

https://github.com/napalm-automation/napalm-yang/blob/augment/napalm_yang/mappings/eos/extractors/oc-if/interfaces.yaml https://github.com/napalm-automation/napalm-yang/blob/augment/napalm_yang/mappings/eos/extractors/oc-ip/ipv4.yaml

Basically, to extract data from the device into the OC framework you just have to define the rules to do so. So far I have implemented an "extractor" for plain text and for xml (I think you only care about the text one right now). Rules are not documented, sorry about that but I guess it shouldn't be difficult to start playing with it and figure out how it works.

[dbarrosop]

@jeremystretch You can start looking at this:

https://github.com/napalm-automation/napalm-yang/blob/augment/interactive_demo/tutorial.ipynb

There are some things to be refactored that will happen soon but you can start playing with the model if you want to take a look. You could do the folllowing:

import napalm_yang
import pprint

config = napalm_yang.BaseBinding()
config.add_model(napalm_yang.oc_platform.platform())

pretty_print(config.model_to_dict())

And start seeing how to map what you want with that structure. I think the platform model is quite "open to interpretation".

[dbarrosop]

Just a quick keepalive. I am almost done, paperwork (aka docs, testing and cleaning) always takes more than anticipated. You can start looking at the docs if you want (WIP but the parts that are relevant for you are probably all there already):

https://napalm.readthedocs.io/en/yang_doc/YANG/index.html

This weekend I will finish the docs and next week I will start merging and releasing stuff so you can start working on this in 1-2 weeks tops.

[jeremystretch]

Excellent! Thanks for the update. Really hoping to dig into the code and familiarize myself more this week.

[dbarrosop]

Ok, this is all out, documentation, libraries, etc... You can find a quick summary here:

https://www.dravetech.com/blog/2017/04/09/napalm-yang.html

Note that @bewing is also working on this. Turns out that the components model is a nightmare but we are discussing how to address it here:

https://github.com/napalm-automation/napalm-yang/issues/39

[dbarrosop]

What's the state of this? Is this something you still need or that you are working on?

[jeremystretch]

@dbarrosop Sorry, NetBox has been sucking up all my dev time lately. I've been following what @bewing has been working on though. How crucial is it that we utilize the OpenConfig platform model for inventory data in the first place, given that it's essentially arbitrary?

[dbarrosop]

I think it makes sense to use the OC models even if use a regular getter. It doesn't make sense to bother reinventing the wheel and it will help migrating code to napalm-yang later on. If the model doesn't make sense at all we should bring it to the OC group.

[bewing]

FYI, there's code now (napalm-automation/napalm-eos#165), I just need to write tests.

[dlasher]

Did this ever make it live?

[dbarrosop]

This repo is deprecated. Head to main napalm repo.