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 | No | Scaling: Dependency on Policy who has no resource to deliver in Beijing | |||||
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 | NA | NA | NA | NA | 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 | NA | No | Yes | Change Mngt: User interface for invoking software upgrade workflow Scaling Manual: no resource | |||
VNF SDK | Yes | NA | NA | NA | NA | NA | NA | NA | |
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 |
VNF Validation (VVP) | NA | NA |