Goals
Improve operational efficiency by consolidating control functions into a single point of entry
- Provide capabilities to rapidly enhance and deploy new operational tooling
Background and strategic fit
<Enter Info Here>
Assumptions
OSAM-UI is built upon the Portal Framework
- Portal Framework facilitates access to VID, CLAMP and other ONAP interfaces.
Requirements
| # | Title | User Story | Importance | Notes |
|---|---|---|---|---|
| 1 | Interface should support configuring the values of the target device. These elements should be driven through models and utilized in the production of the interface. | |||
| 2 | A disaggregated service consists of many elements. These elements are spread across access network devices, physical machine, virtual machines (VMS), containers and services within a server. Each of these elements are related and have various impacts over other elements. The details of the state of each element needs to be represented efficienctly for operations to diagnose and resolve issues. | |||
| 3 | The desegregated element view should show the relationships and type of alarms that occur with the element in the chain. Each element should be clickable to go into details of the device. | |||
| 4 | Device views should be context sensitive to where the interface adjusts to limit the unrelated noise on the page. | |||
| 5 | Meshable interface where elements can be bound to data sources, movable, refreshable (manual or interval based) | |||
| 6 | Views and collections of views can be capture and stored in workspaces | |||
| 7 | Interface to create, schedule and initiate deployment of access node software and firmware updates. System should support tracking and recovering from failures. Pre/Post Health Checks. System should handle migrations of services. Should track subscriber impact. Crawl, Walk and Run Grouping (No constraints). Should be able to support flexible grouping (eg. Device Type, Version Number, Current Load ratio, Site, F/R/R/S, Slot | |||
| 8 | Execution Packages (eg Node-Red, Chef Scripts) should support a DevOps model for the T1-3 operations teams to create and deploy new servcies and flows on demand | |||
| 9 | Execution Packages models developed by operations should automaticically integrate with OSAM platform. Services can be automatically deployed. New Services flows can be executed against 1 or more devices utilizing data from the inventory system and directed to the correct local systems. | |||
| 10 | Ability to initiate backup and restore fuctionality to access device configurations | |||
| 11 | Operations needs the ability to move devices between aggregation layers (eg PMAA and VOLTHA) | |||
| 12 | Interface should support viewing and filtering alarms. Alarm levels should be configurable. Filter should support time range (eg Past Day, Past 5 Days, Past Hour), fixed time range (2017-01-01 1:00 to 2:00), error level, message pattern, source system [Should be covered by Log Stash]. Repeated errors should be truncated and counter should be provided. Should have ability to invert filter. Should support multiple patterns. Should have ability to save a pattern for reuse. | |||
| 13 | Alarms should be represented on a dashboard. Ordered by highest+oldest alarms first by default | |||
| 14 | Device list should show alarm devices, alarm counts and type broken out after the device name. These icons should support drilling into the exact events as well. Devices should rearange their order based on the criticality of the event. Alarm rollups should be represented at the site view. | |||
| 15 |
User interaction and design
Questions
Below is a list of questions to be addressed as a result of this requirements document:
| Question | Outcome |
|---|---|