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
| 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 |
Tree
| Code Block |
|---|
DevXY
shelf
card-0
module-0
card-1
module-1
module-2 |
Open
How to map to internal model?
...
- 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".