OpenECOMP orchestration automates the activities, tasks, rules and policies needed for on-demand creation, modification, or removal of network, application or infrastructure services and resources. The Master Service Orchestrator (MSO) manages orchestration at the top level and facilitates additional orchestration that takes place within underlying controllers. It also marshals data between the various controllers so that the process steps and components required for execution of a task or service are available when needed.
The MSO subsystem runs autonomously within OpenECOMP. Orchestration, in conjunction with policies, can be used to create flexible processes that are guided by business and technical policies and driven by process designers.
The orchestration engine is a reusable service. Any component of the architecture can execute process recipes. Orchestration Services can consume a process recipe and execute it. The Service model maintains consistency and reusability across all orchestration activities and ensures consistent methods, structure and version of the workflow execution environment.
Orchestration processes interact with other platform components or external systems via standard and well-defined APIs. (See SDK?)
The Master Service Orchestrator’s (MSO’s) 's primary function is the automation of end-to-end service instance provisioning activities. The MSO is responsible for the instantiation and release, and subsequent migration and relocation of VNFs in support of overall end-to-end service instantiation, operations and management. The MSO executes well-defined processes to complete its objectives and is typically triggered by the receipt of service requests generated by other OpenECOMP components or by Order by Order Lifecycle Management in Management in the BSS layer. The orchestration "recipe” recipe is obtained from the Service Design and Creation (ASDCSDC) component of OpenECOMP, where all service designs are created and exposed/distributed for consumption.
The MSO runs autonomously within OpenECOMP.
The orchestration engine is a reusable service. Any component of the architecture can execute process recipes. Orchestration Services can consume a process recipe and execute it. The Service model maintains consistency and reusability across all orchestration activities and ensures consistent methods, structure and version of the workflow execution environment.
Orchestration processes interact with other platform components or external systems via standard and well-defined APIs. <<Link to SDK or API page?>>
Controllers (Infrastructure, Network and Application) participate in service instantiation and are the primary players in ongoing service management; for example, control loop actions, service migration and scaling, service configuration, and service management activities. Each controller instance supports some form of orchestration to manage operations within its scope.
Figure 1 illustrates show the use of Orchestration in the two main areas: Service Orchestration two major domains that use orchestration: service orchestration embodied in the Master Service Orchestrator and Service Control MSO and service control embodied in the controllers (Infrastructure, Application and Network Controllers. It illustrates the two major domains that employ orchestration). Although the objectives and scope of the domains vary, they both follow a consistent model for the definition and execution of orchestration activities.
...