Purpose
This template is to be used for the “Parallel Deep Dive Sessions to Align with architecture / Use cases” at the may ONAP developers event
Instructions.
The purpose of each section is to translate the use cases and functional architecture into specific identified needs for the components, and to identify potential projects to be proposed. There are three parts to this exercise:
- Identify needs based on the use case and architecture on this module, and potential dependencies on other modules or external artifacts.
- Group these into projects. Consider that coding, documentation, and testing is required. Include an initial scope for the project.
- If time, mapping the needs into the projects.
The need identification table has the following columns
- Identified need: <slogan for the identified need>
- Brief need description: <a few sentences describing the need>
- Driver:<Related use case or architecture change, if any>
- Dependencies:<identify dependencies on other modules or artifacts (e.g. other onap module, models, …)
- Project: <If time, after the projects are identified, suggest in which project the need would best fit>
Time keeping suggestion: The exercise time is 45 minutes. A good practice would be to split into 20 minutes on need identification and 20 minutes on project proposals.
Exercise output.
ONAP Meeting Session name: <insert onap module name>
Need Identification:
Identified Need | Description | Driver | Dependencies | Project fit |
| Theres a comment around the need for a service framework in addition to oam controller. | It was mentioned that AAF and AJSC are already a part of onap and could solve some of that. | |||
| There was an identified need to have more than just java support from a microservice standard | We want to support things like OAUTH2. We also wan | |||
| There is a need for common frameworks to solve problems operation things have | Things like auditing, logging alerting etc | |||
| There was a need to have enhancements in dmaap etc. how do we handle these? |
Project proposals.
[repeat for each project. Note: This is not a complete project proposal skeleton, only sufficient enough for this discussion]
Project 1: ONAP platform OAM and a platform manager/controller
Project Name:
- The ONAP Platform Manager/Controller will automate deploy/un-deploy of ONAP instance(s) and individual components, monitor its health and perform all platform lifecycle management functions.
Project Description
- The ONAP Platform Manager/Controller will automate deploy/un-deploy of ONAP instance(s) and individual components, monitor its health and perform all platform lifecycle management functions.
Scope:
- embeds resiliency and such that can be used.
Other:
-
Project 2: Common Controller Framework
Project Name:
- Common Controller Framework
Project Description
- Software framework that contains reusable code that can be used across multiple components. The code could be used in other components but would not be an end solution for use cases by itself and would not be deployed on its own
Scope:
- Quickly identify scope, consider: documentation, APIs, models, testing, integration, functionality.
- Note of any particular deliverables to highlight.
- If anything is out of scope, not it down
Other:
- Identify baseline code (if any)
Project 3: Optimizer Framework
Project Name:
- Optimizer Framework for resources used during vnf deployment
Project Description
- Optimizer Framework takes the low level work out of optimizing letting them focus on high level orchestration.
Scope:
- Quickly identify scope, consider: documentation, APIs, models, testing, integration, functionality.
- Note of any particular deliverables to highlight.
- If anything is out of scope, not it down
Other:
- SNIRO is homing optimizer, Conductor is base optimizer framework. Both together will meet the use cases
Project 4: Platform Level Testing
Project Name:
- Platform Level Testing
Project Description
- Platform Level Testing and characterization
Scope:
- Quickly identify scope, consider: documentation, APIs, models, testing, integration, functionality.
- Note of any particular deliverables to highlight.
- If anything is out of scope, not it down
Other:
-
Project 5: Mircoservice Service Discovery, Load Balancer and Registry
Project Name:
- Mircoservice Service Discovery, Load Balancer and Registry
Project Description
- Mircoservice Service Discovery, Load Balancer and Registry
Scope:
- Quickly identify scope, consider: documentation, APIs, models, testing, integration, functionality.
- Note of any particular deliverables to highlight.
- If anything is out of scope, not it down
Other:
- based on Microservice bus from OPEN O
Project 6: End to End flow decomposition across ONAP
Project Name:
- End to End flow decomposition across ONAP
Project Description
- End to End flow decomposition across ONAP
Scope:
- Closed loop, Change management, orchestration, design time
- There is a need around the integration of toolchain to have various common things like security
Other:
-
Project 7: External API Integration
Project Name:
- External API Integration
Project Description
- External API Integration so that external systems can do things like get called and be called. You have to have security considerations around this.
Scope:
-
Other:
-
Project 8: Common platform for modeling
Project Name:
- Common platform for modeling
Project Description
- Common platform for modeling tool
Scope:
-
Other:
-
Project 9: Messaging Bus
Project Name:
- Messaging Bus
Project Description
- Messaging Bus
Scope:
-
Other:
- DMAAP as the base
1 Comment
John Ng
For today's common services breakout session, I would like to propose a project for ONAP platform OAM and a platform manager/controller. The ONAP Platform Manager/Controller will automate deploy/un-deploy of ONAP instance(s) and individual components, monitor its health and perform all platform lifecycle management functions. I would like the group to discuss the need, benefits, use cases and other details required to form the proposed project.