ODLUX Inventory enhancement with treeview

Status ONAP Frankfurt: UX Inventory

Topics of the change

EXTENSION of ONAP Frankfurt app ... by adding an additional treeview.
- The existing functionality like Table and Export should remain as they are.
Inventory view with two "folders" "Tableview","Treeview"

From ConnectApp the "Menue"-entry forwards to "Treeview" with DeviceId
Selction of app from right menue bar opens the "Tableview"
Tableview contains "Frankfurt"-view, including export function
Treeview does not support export
Would be cool: Right click in tableview, Have menue to select device and jump to related treeview
Tree view filter

Data-provider extension for tree view: ODLUX DB API Guilin Extension / Data-Provider

Inventory view with two tabs: "Tableview","Treeview"
- From ConnectApp the "Menue"-entry forwards to "Treeview" with DeviceId
- Selction of app from right menue bar opens the "Tableview"
- Tableview contains "Frankfurt"-view, including export function
- Treeview does not support export
PNF Hardware inventory treeview, showing inventory hierarchy
- Nodes are Subrack, Shelf, Card, Slot
Extension with additional view of "ODLUX Inventory app"
Planned for standards
- ONF Core 1.2
- IETF-hardware
- O-RAN Fronthaul to be analysed
Metamodel "inventory" required
- that bases on internal SDN-R data-provider model
- to be extended with
  - levels
  - nodes
  - node types (Where is the rack, where the card)
Development against NTSim
- Extension SDN-R data-provider inventory model

The following image shows the tabs and an open Inventory table (as in Frankfurt)

data-provider model for inventory is "grouping inventory-entity".

The following elements contain information for building tree view.

Only the elements uuid and parent--uuid are used to create the structure:

leaf (Tree view key is bold)	Table column	Description
uuid	Name	Unique inventory id of this node for this equipment, provided by network element
parent-uuid	Parent	Unique (network element) inventory id of holder. Not existing or null parent-uuid are root elements.
tree-level	Containment Level	(Redundant) Starting with 0 .. ( 0 :root level)
list contained-holder	>no used<	(Redundant) List of uuid of contained equipment.

NodeName	Parent	Name	tree-level	contained-holder
DevXY		power-0	0
DevXY		shelf	0	card-0, card-1
DevXY	shelf	card-0	1	module-0
DevXY	card-0	module-0	2
DevXY	shelf	card-1	1	module-1, modul-2
DevXY	card-1	module-1	3
DevXY	card-1	module-2	3

DevXY
shelf
  card-0
    module-0
  card-1
    module-1
    module2

How to map to internal model?

In ONF Core 1.2

Equipment specified that contains 0-N Equipment.
The fields for equipping are mainly text fields with dates, inventory and ordering numbers.

Mapping ?

There is no formal specification about the "nature" of the equipment ... is it a single card device or a Router with shelf, containing card, containing modules.
{Martin Skorupski] the parent/child association is done by pointing from "holder" to "equipment" using the "occupied-field-replacable-unit (FRU)". The "nature" is given by the vendor in the "manufacture" area. Its values are vendor-specific and due to disaggregation (and re-aggregation) there is not and must not be a kind of standard "nature" - The "nature" of a network function can be exposed from the exposed APIs, but how this maps to equipment is room for innovation and unknown to generic implementations of ONAP.
The mapping can take place by knowing about "textual" keywords or "inventory numbers"-logics of manufacturers
{Martin Skorupski] correct! - it is equipment/vendor/operator specific -
For ietf-hardware (as used by O-RAN Fronthaul please see "iana-hardware" - each NetConf server can define its "nature" (e.g Chassi, Backplane, SFP, ...)
Please use https://www.iana.org/assignments/iana-hardware/iana-hardware.xhtml for the identification of the "nature".