This is a potential draft of a project proposal template. It is not final or to be used until the TSC approves it.
Link to Project Proposal training materials
Project Name:
- Proposed name for the project: SO
- Proposed name for the repository:
so
Project description:
The SO provides the highest level of service orchestration in the ONAP architecture. Currently SO is implemented via BPMN flows that operate on Models distributed from SDC that describe the Services and associated VNFs and other Resource components. Cloud orchestration is currently based on HEAT templates.
In order to support Use Cases 1 and 2 in such a way to promote reusability within ONAP, the goal of this project is to enhance ONAP’s overall orchestration capabilities by aligning and integrating its imperative workflows with a TOSCA-based declarative execution environment.
- This project proposes an expansion of ONAP SO to include a declarative topologically-driven approach to orchestration. Specifically this project proposes to enhance ONAP SO run-time orchestration framework to support orchestration driven from declarative models (TOSCA encoded) as well as integrated or independent BPMN imperative processing extensions that themselves could be TOSCA-aware.
This is envisioned as a multi-release project, which in its maturity will:
- Support TOSCA models in native format as distributed by SDC
- Perform lifecycle operations based on a declarative TOSCA model, including:
- Deployment
- Undeployment
- Scale (Out, In)
- Heal
- Software Upgrade (various forms)
Alternative 1: The following diagram illustrates one option for the internal processing BPMN and TOSCA Orchestrator sub-components within SO. In this approach a separate off-the-shelf TOSCA Orchestrator is incorporated into SO, with a top level BPMN layer delegating well defined orchestration activities to this native TOSCA Orchestrator (see diagram below).
Alternative 2: Another potential approach is shown below, where the BPMN itself in effect is a TOSCA Orchestrator component.
It is envisioned that initial Releases of this project would demonstrate an Alternative 1 approach:
- Demonstrate SO BPMN workflows interacting with an off-the-shelf TOSCA Orchestrator to collectively drive orchestration behavior for at least an instantiation use case
- Demonstrate rainy day handling
- Accomplish the above in a way that is demonstrably extensible to support lifecycle operations such as Scale-In and Scale-Out.
- Obtain and deploy SDC Workflows
- Orchestrate Heat-based and TOSCA-based VNF/VF and Service
- Provide Multi-VIM support foundataion
- Support Multiple VIMs by utilizing the pluggable VIM adapter in a decoupled way
- No direct interface with VIMs from SO workflows
- Start with the OpenStack plugin for ONAP Release 1
- Support REST-based SO NBI
- Interface with SDN-C for network controller and APP-C for network configuration
- Manage A&AI Query and Update
- Monitor SO workflow activities
- High availability / Geo diversity
- Testing
Architecture Alignment:
- How does this project fit into the rest of the ONAP Architecture?
What other ONAP projects does this project depend on?
SDC
AAI
SDN-C
APP-C
DMaaP (?)
How does this align with external standards/specifications?
- TOSCA Simple Profile in YAML Version 1.1
- OASIS TOSCA Simple Profile for Network Functions Virtualization (NFV) Version 1.0
- Are there dependencies with other open source projects?
- ARIA
- ARIA
- Resources:
- Primary Contact Person: DeWayne Filppi (dewayne@gigaspaces.com)
- Names, gerrit IDs, and company affiliations of the committers
- DeWayne Filppi, dewayne@gigaspaces.com, GigaSpace
- Byung-Woo Jun - byung-woo.jun@ericsson.com, Ericsson
- Xin Jin saw.jin@huawei.com, Huawei
- Chuanyu Chen chenchuanyu@huawei.com Huawei
- Seshu Kumar, seshu.kumar.m@huawei.com, HuaweiSteve Smokowski, ss835w@att.com, AT&T
- Rob Daugherty, rd472p@att.com, AT&T
- Gil Bullard, wb5674@att.com, AT&T
- Ting Lu, tl2062@att.com, AT&T
- Jeff Mitryk, jm5764@att.com, AT&T
- Claude Noshpitz, cn5542@att.com, AT&T
- Eric Debeau, eric.debeau@orange.com Orange
Eyal Holzman EyalH@Amdocs.com Amdocs
Barak Dabush Barak.Dabush@amdocs.com Amdocs
- Lingli Deng denglingli@chinamobile.com CMCC
- Chengli Wang wangchengli@chinamobile.com CMCC
- Anbing Zhang zhanganbing@chinamobile.com CMCC
- maopeng zhang zhang.maopeng1@zte.com,cn ZTE
- Zhangzhou-cn zhang.zhou1@zte.com.cn ZTE
- Jinhua Fu fu.jinhua@zte.com.cn ZTE
- Jie Feng feng.jie2@zte.com.cn ZTE
- Li Jiang li.jiang@zte.com.cn ZTE
- Tian Yi tian.yi@zte.com.cn ZTE
- Hui Deng denghui12@huawei.com Huawei
- Thinh Nguyenphu, thinh.nguyenphu@nokia.com, Nokia
- Names and affiliations of any other contributors
- Project Roles (include RACI chart, if applicable)
Other Information:
- link to seed code (if applicable)
https://gerrit.open-o.org/r/#/admin/projects/gso - Vendor Neutral
- if the proposal is coming from an existing proprietary codebase, have you ensured that all proprietary trademarks, logos, product names, etc., have been removed?
- Meets Board policy (including IPR)
Use the above information to create a key project facts section on your project page
Key Project Facts
Project Name:
- JIRA project name:
- JIRA project prefix:
Repo name:
Lifecycle State:
Primary Contact:
Project Lead:
mailing list tag [Should match Jira Project Prefix]
Committers:
rd472p@att.com
ss835w@att.com
Eyal Holzman EyalH@Amdocs.com
Barak Dabush Barak.Dabush@amdocs.com
Xin Jin saw.jin@huawei.com
Chuanyu Chen chenchuanyu@huawei.com
Seshu Kumar, seshu.kumar.m@huawei.com
*Link to TSC approval:
Link to approval of additional submitters: