Page History

Initial Flow discussed for M1.

Image Added

Current change in the flow

Image Added

SO APIs

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 re-usability 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.

Service Orchestrator in ONAP WIKI

Scope:

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).

Image Removed

Alternative 2: Another potential approach is shown below, where the BPMN itself in effect is a TOSCA Orchestrator component.

Image Removed

It is envisioned that initial Releases of this project would demonstrate both alternative approaches:

For 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.

For Alternative 2 approach:

- Demonstrate SO BPMN workflows to drive TOSCA-aware orchestration behavior for VoLTE use case, dependency to VF-C.
- Support lifecycle operations such as Scale-In and Scale-Out.

Architecture Alignment:

...

What other ONAP projects does this project depend on?

SDC (true dependency with SDC SDK)
AAI (using API interface)
SDN-C (using API interface)
APP-C (no existing interface yet)
DMaaP (included as part of SDC SDK)
MSB (no existing interface yet)
VF-C (no existing interface yet)
Multi-VIM (no existing interface yet)

How does this align with external standards/specifications?

...

DeWayne Filppi, dewayne@cloudify.co Cloudify
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 Huawei
Steve Smokowski, ss835w@att.com AT&T
Rob Daugherty, rd472p@att.com AT&T
John Choma, jc1348@att.com AT&T
Gil Bullard, gil.bullard@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
Christian Destré, christian.destre@orange.com Orange
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
Joe Zhang, 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
Yan Yang yangyanyjy@chinamobile.com CMCC
Ni Lu mail luna.lu@huawei.com Huawei
Bin Hou mail bin.hou@huawei.com Huawei
Hrvoje Kegalj hrvoje.kegalj@hr.ibm.com IBM
Ethan Lynn ethanlynnl@vmware.com VMware
Earle West ew8463@att.com AT&T
Zhou Jun mail zhoujun8@huawei.com Huawei
Heliu Zhong zhongheliu@boco.com.cn
Yuanwei Yang yangyuanwei@boco.com.cn
Victor Morales, victor.morales@intel.com Intel

...

Project Roles (include RACI chart, if applicable)

...

Catherine Lefèvre

...

cl664y@intl.att.com

...

Belgium UTC +2

...

Alex Vul

...

alex.vul@intel.com

...

USA UTC-8

...

Tal

...

Chicago, IL, USA UTC -5

...

Victor Morales

...

Other Information:

link to seed code (if applicable)
https://gerrit.onap.org/r/#/admin/projects/mso
https://gerrit.onap.org/r/#/admin/projects/mso/chef-repo
https://gerrit.onap.org/r/#/admin/projects/mso/docker-config
https://gerrit.onap.org/r/#/admin/projects/mso/libs
https://gerrit.onap.org/r/#/admin/projects/mso/mso-config

...

if the proposal is coming from an existing proprietary codebase, have you ensured that all proprietary trademarks, logos, product names, etc., have been removed?

...

Use the above information to create a key project facts section on your project page

Key Project Facts

Project Name:

JIRA project name: Master Service Orchestrator (can be renamed as Service Orchestrator)
JIRA project prefix: MSO- (can be renamed as SO-)

Repo name: mso (can be renamed as 'so' ?)
Lifecycle State:
Primary Contact:
Project Lead:
mailing list tag [Should match Jira Project Prefix]
Committers:
Rob Daugherty, rd472p@att.com, AT&T
John Choma, jc1348@att.com, AT&T