Summary of the Teams commitements to support Beijing functional Requirement.
This is summary of outcome of Use case Sub-Committee.
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 | ||
| A&AI | Yes | Yes | Yes | Yes | NA | 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 | |||||||
| APPC | NA | NA | No | No | NA | NA | NA | NA | Change Mngt: not impacted for Beijing, because Use case is about L3 VNF. L4 to L7 would be impacted. Scaling Auto and Manual: Lack of ressources. Lack of detailed requirements. |
| CLAMP | NA | NA | ? | ||||||
| Common Controller SDK | NA | Yes | Yes | Yes | NA | NA | NA | NA | Change Mngt: Ansible server support |
| DCAE | No | NA | No | No | NA | NA | NA | NA | Scaling: Requirements were not defined to the level necessary for the team to plan. HPA: Not priority |
| DMaaP | NA | NA | |||||||
| Documentation | NA | NA | |||||||
| External API Framework | NA | NA | |||||||
| Holmes | NA | NA | Yes | No | NA | NA | NA | NA | Scaling: Need more details about the requirements. |
| Yes | Yes | Yes | |||||||
| Logging Enhancements Project | NA | NA | |||||||
| 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 | |||||||
| Multi VIM/Cloud | Yes | NA | Yes | ||||||
| MUSIC | 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 | |||||||
| 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 | Yes | ||||||
| Policy Framework Project Proposal | Yes | NA | No | NA | NA | NA | NA | NA | Scaling: Lack ressource |
| Portal Platform Project Proposal | NA | NA | |||||||
| SDN-C | NA | Yes | Yes | Yes | NA | NA | NA | NA | Change Mngt: In-place software upgrade execution using Ansible |
| Service Design & Creation | Yes | NA | ? | Yes | |||||
| 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 | NA | NA | Yes | Yes | NA | NA | NA | NA | HPA: Not priority For other requirements did not reach out to VF-C |
| VID | NA | Yes | ? | Yes | Change Mngt: User interface for invoking software upgrade workflow | ||||
| VNF SDK | Yes | NA | NA | NA | NA | NA | NA | NA | |
| VNF Requirements | Yes | NA | No | ||||||
| VNF Validation (VVP) | NA | NA | |||||||