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 Alexander Vul)
- 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 | |||||
| A&AI | 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. |
| Application Authorization Framework | NA | NA | NA | NA | ||||||||||
| 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. |
| CLAMP | NA | NA | NA | NA | No | No | NA | NA | Scaling: Dependency on Policy who has no resource to deliver in Beijing | |||||
| Common Controller SDK | NA | NA | Yes | Yes | Yes | Yes | Yes | Yes | NA | NA | NA | NA | Change Mngt: Ansible server support | |
| DCAE | 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 |
| DMaaP | NA | NA | Yes | Yes | NA | |||||||||
| Documentation | NA | NA | NA | NA | ||||||||||
| External API Framework | NA | NA | NA | NA | NA | NA | NA | NA | NA | NA | NA | NA | NA | Initial code release |
| Holmes | NA | NA | NA | NA | NA | NA | NA | NA | ||||||
| Yes | Yes | NA | NA | Yes | ||||||||||
| Logging Enhancements Project | 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 | ||||||
| Microservices Bus | 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. | |||||
| Modeling | 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. | |||||
| Multi VIM/Cloud | Yes | NA | NA | NA | ||||||||||
| MUSIC | NA | NA | NA | NA | ||||||||||
| ONAP CLI | NA | NA | Yes | Yes | NA | 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. | |||||
| ONAP Operations Manager | NA | NA | NA | NA | ||||||||||
| ONAP Optimization Framework | Yes | Yes | Yes | Yes | NA | NA | NA | NA | Change Mngt: Scheduling. Only VNF software upgrade Scaling Auto and Manual: within the Data Center (assuming License information is available) | |||||
| ONAP Usecase UI Project Proposal | NA | NA | N/A | Yes | ||||||||||
| Policy Framework Project Proposal | Yes | Yes | NA | No | NA | NA | NA | NA | NA | Scaling: Resources found for vDNS, but APPC is unable to commit fully. Policy will do as much as possible in conjunction with APPC's ability. | ||||
| Portal Platform Project Proposal | NA | NA | NA | NA | NA | NA | NA | NA | ||||||
| SDN-C | NA | NA | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | NA | NA | NA | Change Mngt: In-place software upgrade execution using Ansible |
| Service Design & Creation | Yes (based on INTEL contribution) | WIP | NA | NA | Yes | YES | Yes (based on NOKIA contribution) | YES | No | No | No | Scaling Manual: no resource | ||
| Service Orchestrator | Yes | Yes | Yes | Yes | Yes | Change Mngt: Change workflow design and execution for in-place software upgrade Note: The current commitment is based on the discussions and promises of availablity of coding resources for the respective function implementation. | ||||||||
| VFC | Yes | WIP | NA | NA | Yes (but the auto scaling process is not very clear now) | Yes | Yes | Yes | NA | NA | NA | NA | NA | scaling Auto: VF-C will provide the scaling API, but the auto-scaling process is not very clear now. For other requirements did not reach out to VF-C |
| VID | NA | Yes | NA | Yes | Yes | NA | NA | NA | Change Mngt: User interface for invoking software upgrade workflow Scaling Manual: no resource | |||||
| VNF SDK | Yes | No | NA | NA | NA | NA | NA | NA | NA | M4: Model not published. | ||||
| VNF Requirements | Yes | Yes | Yes | Yes | Yes | Still investigating | Still investigating | NA | Auto scaling and Manual Scaling covered by scaling use case component planned for Beijing. Scope of PNF work dependent on definition of PNF, VNFRQTS-160 | |||||
| VNF Validation (VVP) | NA | NA | NA | NA | ||||||||||