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 |
| Homing function | View of placement | A&AI will have a view of where capacity will be | ||
| orchestration of multiple VNFs | ||||
| imperative vs. declarative approaches | ||||
| VNF configuration | interface between SO and AppC | |||
| Platform orchestrator and resource orchestrator | provider software that runs on top of OpenStack (and others???) resource orchestrator needed for A&AI (pre-populate database) – need further discussion about role | |||
| support for Multi-VIM | merge with platform orchestrator? needs more discussion | |||
| service optimization framework | for instantiation, changes, etc. | A&AI, DCAE, Policy | ||
| SO/orchestrator federation | geographically distributed orchestrators (scale and federation); hierarchical | could relate to other entities as well | ||
| SO scale | geographically distributed orchestrators (scale and federation); hierarchical | |||
| service chaining | execute service chain per user | |||
| scaling/healing of underlying components | ||||
| Is this a framework or a single multi-technology orchestrator? | ||||
| monitoring | monitor the orchestrator and recovery | |||
Project proposals.
[repeat for each project. Note: This is not a complete project proposal skeleton, only sufficient enough for this discussion]
Project 1:Service Orchestrator
Project Name: Service Orchestrator
- Provide a brief project name.
Project Description
- Take and evolve the service orchestration module to support various controllers
Scope:
- Service orchestration
- interface to "multi-VIM"
- dependencies to SDC and modeling
- non-functional impacts
- support for YANG, Heat, TOSCA
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: Multi-VIM
Project Name: Multi-VIM
- Provide a brief project name.
Project Description
- Support for multiple VIMs
- testing
- Provide a high level description of the project
Scope:
- Common interface for multiple VIMs
- testing
- 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)
4 Comments
Chengli Wang
How MSO coordinate SDN-C(L0-L3)&APP-C/VF-C(L4-L7) to work sequentially when there are dependencies between SDN?network?/NFV?VNF?. for instance, if we want to provision SFC based on VNFs, we must instantiate related VNFs firstly and then chain them together.
Hector Anapan-Lavalle
APPC's IaaS Adaptor presently runs OpensStack API commands using the CDP-PAL library. MSO uses the woorea library which is an OpenStack API library. What I am wondering is what APPC's role will/should be in the multi VIM project?
KJ - Kaustubh Joshi
How do the needs identified in the first table map to the projects? Some things such as SO scale and federation belong to the main orchestrator project. However, other identified needs seem to belong to other (new) projects. For example, the "scaling and healing of underlying components" should be in the closed loop project. Also, Homing and optimization should be a separate project so that it can be used by the controllers (and other services) in addition to the SO.
Yue Yuan
The service orchestrator should leverage the underlayer capabilities to create, start vNFs in a network service through same interface no matter GVNFM or SVNFM. The northbound interface of an VNFM should align with ETSI spec. The MSO in openECOMP this time leverage the openstack heat capability to create a instance of VNF, then the other part of LCM capabilities from APP-C to manage the VNF. I proposed if use openstack heat capability should be decided by VNFM instead of service orchestrator.