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 |
| different types of Cloud Infrastructure | ||||
| multiple sites of Cloud Infratructure | ||||
| controller framework to deploy vnfs, micro-services,etc. | ||||
| registration and discovery of Cloud Infrastructure capabilities | Modeling: service, infrastructure,etc | |||
| Support SDN | SDN-C | |||
| Support TOSCA , HEAT Template | ||||
| Support DCAE | ||||
| Support SDC | ||||
| Support vCPE and VoLTE | ||||
| support homing locating of cloud infrstrature |
Project proposals.
[repeat for each project. Note: This is not a complete project proposal skeleton, only sufficient enough for this discussion]
Project 1:
Project Name: Multi-VIM framework
- Provide a brief project name.
Project Description
- Provide a high level description of the project
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 2:
Project Name: Multi-VIM Homing Locator
- Provide a brief project name.
Project Description
- Provide a high level description of the project
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:
Project Name: Multi-VIM plugin projects
- Provide plugins for OpenStack, VMware VIO, Microsoft Azure, etc
Project Description
- Provide a high level description of the project
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)
7 Comments
Eric Debeau
Concerning Project3, I believe that we do not need OpenStack Plugin as OpenStack is the default VIM. Using various VIM will have an impact on all existing components that should be taken into account.
Stephen Gooch
One reason to have OpenStack plugins is backward compatibility. i.e. one plugin for Kilo, Mitaka, Newton, etc.. Functionality can be modified and added as new features become available and APIs evolve without having to re-qualify existing OpenStack plugins.
xinhuili
The term of back compatibilty is used more for software upgrade capability. OpenStack plugin here is targted to support mulit-versoned OpenStack.
Aayush Bhatnagar
Some additional aspects we should consider -
1. We may need to specifically include the integration aspects of Multi-VIM with the DCAE.
These two projects will need to evolve together, as the DCAE information collection for different VIMs would drive the downstream ONAP processes and integrations.
2. The other aspect is the handling of hybrid cloud envrionments - where one VNF may need to be deployed on one VIM, while the other VNFs may be deployed on other VIMs.
A concrete example includes - vOSS/vBSS VNFs - some of which may be on Azure, while the vEPC/vIMS may reside on Openstack and VMware.
3. Fault tolerance policies for different VIMs would be different. For example, in VMware we have DRS features for disaster recovery. Hence, the "policies" for DR/HA would change as the VIM changes. Hence, we should recognize the dependency of multi-VIM support for the policy engine as well.
Bin Yang
Agree with your point that these two projects need to evolve together. Multi-VIM project is working on proposal and will cover this topic for sure.
xinhuili
interesting points. We the multivim team has had some discussion related to these points. I believe there will be more synergy between us.
Alok Gupta
I think DCAE architecture addresses the scope discussed above in Aayush's comments. DCAE does and can handle multiple VIM and also work with multiple cloud infrastructure. The ONAP architecture needs to be robust enough to handle events from any environment; it will perform a correlation function that identify root cause and recommend a path to rectify the problem via closed or open loop. Perhaps we can review this in our next meeting.