Requirement Jira: https://lf-onap.atlassian.net/browse/POLICY-2952

The PoC shall focus on: 
Demonstrate Control loops defined and deployed using TOSCA
Use a design time catalog for Control Loops for a complete storage of all the artifacts from different DT systems
Show design time systems can populate the Design Time control loop catalog
               -DCAE-MOD interacting with the design time catalog

               -SDC interacting with the design time catalog

Show TOSCA defined control loops being onboarded and deployed

Capabilities to be delivered:

Storage of Control Loop Element types in a design time catalogue
Storage of Control Loop types in a design time catalogue
Onboarding of Control Loop Element types from a zip file/CSAR/Yaml file containing a TOSCA service template that defines Control Loop Element types, see these examples of such TOSCA service templates here
GUI support for composition of Control Loop Types, resulting in a Yaml file containing a TOSCA service template that defines a Control Loop type, see an example of such a TOSCA service template here.
Composition of a Control Loop Type into a package/service that can be distributed by SDC over DMaaP, and parameterization of the common properties for the Control Loop type
Reception of the distribution of a Control Loop Type package/service sent by SDC from DMaaP and commissioning of the Control Loop Type in the Control Loop Runtime

Constraints:

The software should be integratable into SDC
The software should be possible to run standalone
The software will be developed as a new module in policy-gui
Follow the ONAP style guide and new methodology for client development
Use the policy-distribution component for commissioning from SDC

1 Introduction

This page provides details on what is the current support for designing ControlLoops in SDC, and the changes proposed to work with Tosca Controlloop runtime components in CLAMP.

It briefly states the procedure to design a Control Loop starting from service creation, adding the required ONAP component artifacts, policy and VF in the composition phase of SDC and finally distributing it to the CLAMP for further process. SDC provides an interface for distributing the modeled services to the run time components.

SDC receives a VNF package, this package can be HEAT based or Tosca based.
SDC needs to store the information in its internal DB.

2 Terminology

This section describes the terminology used in the system.

2.1 SDC Terminology

TOSCA Service template: These templates are used to specify the topology and orchestration of services. SDC uses Tosca templates and the Tosca spec-defined CSAR package to distribute the definition of new services.

SDC: Service Design and Creation is the ONAP visual modeling and design tool. It provides a graphical interface for onboarding/designing resources (such as VNFs, PNFs, CNFs) and designing services composed of such resources that can be distributed to other ONAP components

SDC catalog: SDC maintains a design catalog of onboarded resources, designed services along with their artifacts (if any) from which other ONAP components (like SO, DCAE, CLAMP etc) can access them

SDC workflow: CSAR package for the designed service which is needed to instantiate the service. After the service is designed in UI, the CSAR is stored in SDC catalog. Distribution will send a notification over DMaap, and ONAP components that are registered and interested can callback to SDC catalog for the CSAR for a particular service

SDC distribution: SDC communicates with run time components using DMaaP. Once a service is certified, a user can choose to distribute the service. On distribution SDC sends a notification to a predefined Dmaap topic.
All components can subscribe to this topic to receive notifications once they are send.

2.2 Control loop Terminology

Control Loop Type: A definition of a Control Loop in the TOSCA language. This definition describes a certain type of a control loop. The life cycle of instances of a Control Loop Type are managed by CLAMP.

Control Loop Instance: An instance of a Control Loop Type. The life cycle of a Control Loop Instance is managed by CLAMP. A Control Loop Instance is a set of executing elements on which Life Cycle Management (LCM) is executed collectively. For example, a set of microservices may be spawned and executed together to deliver a service. This collection of services is a control loop.

Control Loop Element Type: A definition of a Control Loop Element in the TOSCA language. This definition describes a certain type of Control Loop Element for a control loop in a Control Loop Type.

Control Loop Element Instance: A single entity executing on a participant, with its Life Cycle being managed as part of the overall control loop. For example, a single microservice that is executing as one microservice in a service.

CLAMP Control Loop Runtime: The CLAMP server that holds Control Loop Type definitions and manages the life cycle of Control Loop Instances and their Control Loop Elements in cooperation with participants.

2.3 SDC Architecture

Open

3 Controlloop Design

The instructions below will enable to design a Control Loop. There are different phases to the Closed Loop (CL) design:

Step 1: Design a closed loop template and associate it to a Service, the template represents the theoretical flow of the CL. (DCAE-DS/SDC)

Step 2: Generate a deployment artifact that can be ingested by the DCAE, Policy Framework or any other ONAP component

Step 3: Distribute the control loop to CLAMP, the csar is distributed to CLAMP over Dmaap

Step 4: Submit the closed loop, meaning provision Policy/DCAE with closed loop data. (CLAMP)

Step 5: Deploy the closed loop, it initiates the deployment of the micro service on ONAP component side (CLAMP)

3.1 Import and Onboard

Different Network functions are imported and created in to SDC dashboard. This can stand as an example for creating ControlLoopElements
SDC provides a graphical interface for onboarding/designing resources (such as VNFs, PNFs, CNFs) and designing services composed of such resources

Open

3.2 Add service

Add a service with a service name and any suitable category. This can stand as an example to create ControlLoop
Onboard the resources and service, This will ensure service and resources are stored in the catalog.

3.3 Composition of ControlloopType

Composition of ControlLoopType in to service that can be distributed over Dmaap.

Existing SDC logic for adding dependencies, links, connection points between resources in a service can be re-used with no effort for composition

3.4 Change properties and values

Properties assignment of resources and service can be used without any change.
Each property can maintain a default value or marked as "declared at input" for setting values at a later stage

3.5 Download designed CSAR or template (if desired)

Once designed, a Tosca template or CSAR (Tosca template + any artifacts) can be downloaded

3.6 Distribute a service with Controlloop

In this step, the user distributes the models to the ONAP components, like DCAE, Policy subsystems etc

After a model is uploaded to a VNF, the status icon of the VNF changes to from “Design” to “Activated” in the ONAP Portal GUI.

• The ONAP distribution model is based on a publisher subscriber model.

• SDC defines two topics in Dmaap, one for publishing notification and one for reading notification status events.

• Using the distribution client, a component can easily subscribe to receive notifications regarding services distributed from SDC.

• The distribution client allows the applications to define what type of artifacts they want to download from a service.

• The component can choose to receive specific artifact types or to receive the whole CSAR package.

• Once a distribution client receives a notification, it will access an SDC instance defined in it, to pull the artifacts.

• The retrieved artifacts will be download from SDC using REST API.

• Once the artifacts are downloaded the application posts a status regarding the download status.

• Since the SDC publishes notifications we need the status to show the state of the distribution across the different applications.

From the SDC HOME page, click CATALOG and search for the service (it will be in Waiting For Distribution state)

Select the service that is Ready for Distribution, click Distribute (top right corner)

To Monitor Distribution, click on Distribution on the left pane

3.7 Verify CLAMP GUI for design template

At this point we can open the CLAMP GUI and verify that the DCAE microservice design template is in place as shown below.

4 Changes proposed in SDC

Note: Some of the changes proposed below might already be supported in SDC and may not be needed. Verification of such can be part of POC and actual changes can be considered.

4.1 Solution Proposal 1: Use of existing SDC controlloop design to produce Tosca service template

•  

  • Predicted minor design changes listed in below 4.1.2, 4.1.3, 4.1.4 sections

  • Verify Design, Composition, Properties, Distribution and Deployment of ControlLoop with current demo usecase

  • Note: This will not satisfy below 2 requirements, as it works as an integral component of SDC

    • The software should be possible to run standalone

    • The software will be developed as a new module in policy-gui

4.2 Solution Proposal 2: New editor for ControlLoop components as a separate plugin similar to Apex editor