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

Topics of extension

• 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

Example view Table View

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

Example view Tree View (with details)

Example

Table

Tree

DevXY
shelf
  card-0
    module-0
  card-1
    module-1
    module-2

Open

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".