Beijing Functional Requirements
Summary of the Teams commitments to support Beijing functional Requirement.
This is summary of outcome of Use case Sub-Committee and effort from:
HPA (main contact @Alex Vul (Deactivated))
Change Management (Main contact @Ajay Mahimkar)
Scaling (main contact @Scott Blandford)
5G/PNF support (main contact @Vimal Begwani)
Legend
Yes: Committed by PTLs to Beijing Release
No: Not committed to Beijing Release
NA: Project not impacted by functional requirement, requirement not defined enough to make formal decision.
Project Name | Functional Requirements | Comments | ||||||||||||
| HPA | ChangeMngt | Scaling Auto | Scaling Manual | PNF | Network Slicing | Data Collection | Path Selection |
| |||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| M1 Commitment | M4 result | M1 Commitment | M4 result | M1 Commitment | M4 result | M1 Commitment | M4 result | M1 Commitment | M4 result |
|
|
|
|
Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | NA | NA | NA | Change Mngt, Scaling: Functionality already exist in Amsterdam. New way to exercice the API. No schema change required.
| |
N/A | N/A | N/A | Yes, AAF is now ONAP Only | N/A | Yes | N/A | Yes | N/A | N/A | N/A | N/A | N/A | AAF was not managed in ONAP for Beijing. Instead, we used this time to take the major features desired from AT&T production, including Certman, OAuth2 and other elements. AAF project is now ONAP First. This means that starting with Casablanca, requirements and results now come from the community, will have M1 Commitments, etc. | |
APPC | NA | NA | Yes | Yes | No | No | Yes | Yes
| NA | NA | NA | NA | NA | Change Mngt: not impacted for Beijing because Use case being focuses on an L3 VNF. APPC is impacted for this change management functional requirement for L4 to L7 VNFs. APPC will support In Place software upgrade in Beijing. Scaling Auto: Lack of detailed requirements and resources. |
NA | NA | NA | NA | No | No | NA | NA | NA | NA | NA | NA | NA | Scaling: Dependency on Policy who has no resource to deliver in Beijing | |
NA | NA | Yes | Yes | Yes | Yes | Yes | Yes | NA |
| NA | NA | NA | Change Mngt: Ansible server support | |
NA | NA | NA | NA | NA | NA | NA | NA | Event for PNF discovery to be added (validate whether prov only or need dev). If dev needed and not committed then can deliver the solution without DCAE for Beijing | WIP as of 03/28 (the PNF Registration Handler, aka prh, work is in the process of being contributed. Code coverage 63%, but currently encountering problems in CLM scan reporting "CLM server error", LF helpdesk ticket #54190) | NA | NA | NA | HPA: Not priority | |
NA | NA | NA | NA | NA | NA | NA | NA | NA | NA | NA | NA | NA | NA | |
NA |
| NA |
| NA |
| NA |
|
|
|
|
|
|
| |
NA | NA | NA | NA | NA | NA | NA | NA | NA | NA | NA | NA | NA | Initial code release | |
NA | NA | NA | NA | NA | NA | NA | NA | NA | NA | NA | NA | NA |
| |
Yes |
| Yes |
| NA |
| NA |
| Yes |
|
|
|
|
| |
NA |
| NA |
| NA |
| NA |
|
|
| NA | NA | NA | Scaling is possible via standard k8s config - but not yet tested for elasticsearch and logstash containers Network slicing has not been prototyped (independent of any k8s component - not specific to the elk stack) Data collection is possible via PVs exposed on /dockerdata-nfs share - via standard k8s volumes - but not tested Patch selection is not applicable - but needs to be verified | |
NA |
| NA |
| NA |
| NA |
| NA |
| NA | NA | NA | No modification is needed in MSB project specifically to support all these functionalities so far. If you think there are any new requirements needed, please let us know. | |
Yes |
| NA |
| NA |
| NA |
| NA |
| NA | NA | NA | modeling project is responsible for a tool: Parser, modeling committee is responsible for modeling spec, HPA will be related parser. | |
Yes | Yes | NA |
| NA |
| NA |
| NA |
| NA | NA | NA |
| |
NA | NA | NA | NA | NA | NA | NA | NA | NA | NA | NA | NA | NA |
| |
NA |
| NA |
| Yes | Note1 | Yes | Note1 | NA | YES Note2 | NA | NA | NA | Mostly HPA will be captured as part of Templates (TOSCA/HEAT). so CLI won't get oppourtunity to operate on HPA. But if Services provides API to handle the HPA, those can be incorporated. So after M2/M3, things will be very clear. so CLI marked HPA as NA. Note1: SO does not expose the REST API for scaling yet. so CLI is not in postiion to support this feature. Note2: PNF support was not initially planned during M1, but as part of M3, it got identified to support and is enabled now. | |
NA |
| NA |
| NA |
| NA |
|
|
|
|
|
|
| |
Yes | Yes | Yes | N/A Note 1 | Yes | No Note 2 | Yes | No Note 2 | NA |
| NA | NA | NA |
| |
NA |
| NA | ||||||||||||