Table of Contents | ||
---|---|---|
|
...
Scope
What is this release trying to address
- E2E Network Slicing - two Jira opened EXTAPI-449 - E2E Network Slicing: Lifecycle management operations – standard interface OPEN Enhancements for Service activation, deactivation, termination (based on TMF 641) and EXTAPI-450 - E2E Network Slicing: KPI monitoring OPEN KPI Monitoring e.g., based on TMF 628. Discussion on the requirements for Guilin with Priyadharshini B Swaminathan Seetharaman Guobiao Mo
- Slides presented covering the NBI requirement for E2E External API Framework: 5GNetworkSlicing_ExtAPI_20200610_v1.0.pptx
- Actions/updates:
- Briefly discussed reg. the use of TMF 641 APIs for service activation/deactivation/termination. We will go ahead with the proposed approach based on last week's discussion to use ServiceState of Service object
- Discussed with @Jack Pugaczewski reg. use of (modernized) TMF 628 for "On Demand" PM collection.
- Share DES APIs (that would have been invoked from UUI), as well as the typical response from DES for a KPI monitoring request – can be the draft version. Guobiao Mo LUKAI
- Get the draft updated TMF 628 swagger from Jack. Adrian OSullivan
- Try to map the request from UUI to TMF 628 onDemandCollection Priyadharshini B Adrian OSullivan Swaminathan Seetharaman
- If the mapping looks reasonable, make a simple start w.r.to implementation in Guilin release – this will have impact in UUI and ExTAPI. LIN MENG Swaminathan Seetharaman to confirm resources.
- Update the ppt with relevant details. Priyadharshini B/ Swaminathan Seetharaman/Guobiao Mo
- Last week Items:
- Macromode for Guilin, EXTAPI-258 - "Macro" mode OPEN Former user (Deleted) - Support for when SDC instantiationType = macro
Use Cases
The existing use cases are still going to be supported ( BBS, CCVPN ) in the Guilin Release
5G E2E Network Slicing Use case have plans to use External API Service Order APIs to Create, Delete and modify ( activate / deactivate) Communication Services. There is minor changes to reuse the existing Service Order APIs to activate and deactivate Service Instances via ServiceState.
The major impact is for the catering Performance Management and the possible inclusion of a subset of the TMF 628 API. See
- Slides presented covering the NBI requirement for E2E External API Framework: 5GNetworkSlicing_ExtAPI_20200610_v1.0.pptx
Platform Maturity
Platform Maturity (i.e., S3P items) Guilin Release Platform Maturity
Minimum Viable Product
- Documentation of User Stories; Use Cases and Interactions (e.g., swagger ); Data Models (e.g., JSON); Interface Profiles and Functional Definition;
- ONAP Component Mapping and Functional Analysis;
- Code contribution for External API Framework functionality.
Functionalities
List the functionalities that this release is committing to deliver by providing a link to JIRA Epics and Stories. In the JIRA Priority field, specify the priority (either High, Medium, Low). The priority will be used in case de-scoping is required. Don't assign High priority to all functionalities.
Table of Contents | ||
---|---|---|
|
Overview
Project Name | Enter the name of the project |
---|---|
Target Release Name | Guilin Release |
Project Lifecycle State | Incubation.( Refer to ONAP Charter, section 3.3 Project Lifecycle for further information) |
Participating Company | AT&T, CenturyLink, China Mobile, Huawei, Orange, Verizon, Amdocs, Ciena, Wipro, HCL, Tech Mahindra, Netcracker, MEF, TMF |
Scope
What is this release trying to address
- Support TSC must have ONAP requirements Guilin Release Requirements
- implements as much TSC must feature as possible
Scope Priority Committer Lead Resources Committed Epic Dependencies TSC Must have high Adrian O'Sullivan, Priyadharshini BJira Legacy server System Jira serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 key EXTAPI-465 - E2E Network Slicing - EXTAPI-449 - E2E Network Slicing: Lifecycle management operations – standard interface OPEN Enhancements for Service activation, deactivation, termination (based on TMF 641)
- Slides presented covering the NBI requirement for E2E External API Framework: 5GNetworkSlicing_ExtAPI_20200610_v1.0.pptx
- Implementation of TMF 641 APIs for service activation/deactivation/termination. We will go ahead with the proposed approach based on last week's discussion to use ServiceState of Service object as part of EXTAPI-449
- Specification work on (modernized) TMF 628 for "On Demand" PM collection and future mapping to DES API's
- Slides presented covering the NBI requirement for E2E External API Framework: 5GNetworkSlicing_ExtAPI_20200610_v1.0.pptx
- Macromode for Guilin, EXTAPI-258 - "Macro" mode OPEN Former user (Deleted) - Support for when SDC instantiationType = macro
Use Cases
The existing use cases are still going to be supported ( BBS, CCVPN ) in the Guilin Release
5G E2E Network Slicing Use case have plans to use External API Service Order APIs to Create, Delete and modify ( activate / deactivate) Communication Services. There is minor changes to reuse the existing Service Order APIs to activate and deactivate Service Instances via ServiceState.
The major impact is for the catering Performance Management and the possible inclusion of a subset of the TMF 628 API. See
- Slides presented covering the NBI requirement for E2E External API Framework: 5GNetworkSlicing_ExtAPI_20200610_v1.0.pptx
- Only Specification aspects of the mapping to be covered during Guilin Release, with implementation of new API tentatively planned for Honolulu Release
Jira Legacy server System Jira serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 key EXTAPI-450
Platform Maturity
Platform Maturity (i.e., S3P items) Guilin Release Platform Maturity
Minimum Viable Product
- Documentation of User Stories; Use Cases and Interactions (e.g., swagger ); Data Models (e.g., JSON); Interface Profiles and Functional Definition;
- ONAP Component Mapping and Functional Analysis;
- Code contribution for External API Framework functionality.
Functionalities
List the functionalities that this release is committing to deliver by providing a link to JIRA Epics and Stories. In the JIRA Priority field, specify the priority (either High, Medium, Low). The priority will be used in case de-scoping is required. Don't assign High priority to all functionalities.
18 Non functionals :
10 - TSC MUST HAVE (please indicate where you plan to contribute)
Requirement Epic | TSC Priority | EXTAPI Epic(s) and/or EXTAPI Story(ies) | Committed Contributors | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
REQ-323 - Each project will update the vulnerable direct dependencies in their code base TO DO | RANK #1 - Must Have |
|
| ||||||||||
RANK #1 - Must Have |
|
| |||||||||||
RANK #1 - Must Have |
| ||||||||||||
RANK #1 - Must Have |
| ||||||||||||
RANK #1 - Must Have |
| ||||||||||||
RANK #1 - Must Have |
| ||||||||||||
RANK #1 - Must Have |
| ||||||||||||
RANK #1 - Must Have |
| ||||||||||||
REQ-349 - Each ONAP project shall define code coverage improvements and achieve at least 55% code coverage TO DO | RANK #1 - Must Have |
| |||||||||||
RANK #1 - Must Have |
|
1 - TSC PRIORITY 2 Continuity (please indicate where you plan to contribute)
RANK #2 – Continuity |
|
7- TSC PRIORITY 3 PTL GO/NO GO (please indicate where you plan to contribute)
| |||
| |||
| |||
| |||
REQ-360 - Application config should be fully prepared before starting the application container TO DO |
| ||
REQ-350 - Each ONAP project shall improve its CII Badging score by improving input validation and documenting it in their CII Badging site. TO DO |
| ||
|
Epics
Jira Legacy | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
...
Sub-components are repositories are consolidate in a single centralized place. Edit the Release Components name for your project in the centralized page.
...
Platform Maturity
Refering to CII Badging Security Program and Platform Maturity Requirements, fill out the table below by indicating the actual level , the targeted level for the current release and the evidences on how you plan to achieve the targeted level.
...
List the API this release is expecting from other releases.
Prior to Release Planning review, Team Leads must agreed on the date by which the API will be fully defined. The API Delivery date must not be later than the release API Freeze date.
Prior to the delivery date, it is a good practice to organize an API review with the API consumers.
API Name | API Description | API Definition Date | API Delivery date | API Definition link (i.e.swagger) |
---|---|---|---|---|
SDC: Catalog API | Exposes Service Catalog | TBD | TBD | https://wikilf-onap.onapatlassian.orgnet/wiki/display/DW/SDC+API |
SO: Service Instantiation API | Requests for Service Instantiation | TBD | TBD | |
AAI: Service Inventory API | Query for Service Inventory | TBD | TBD | |
DMaaP: Events API | Query for AAI_EVENTS and SDC Distribution Events | TBD | TBD |
...
Risk identified | Mitigation Plan | Contingency Plan |
---|---|---|
TBD | TBD | TBD |
Resources
Fill out the Resources Committed to the Release centralized page.
Release Milestone
The milestones are defined at the Release Level and all the supporting project agreed to comply with these dates.
...
Each project must edit its project table available at Project FOSS.
Charter Compliance
The project team comply with the ONAP Charter.