Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.

...

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

image9Image Modified

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 Use of existing SDC controlloop design to produce Tosca service template

4.1.1 Verification activity with SDC and current CLAMP runtime

A verification activity is needed with current SDC controlloop support, and to ensure the ToscaServiceTemplate artifact produced with current SDC is complaint to CLAMP runtime.

Observation is that, it should work as it is.

  • 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.1.2 Model changes and new models for Controlloop types

Include model changes (if any) for defining properties of a Participant, ControlLoopElement and ControlLoop
Example: Multiple elements in ControlLoopElementDefinition properties
topology_template:
  ...
  node_templates:
    ...
    org.onap.domain.pmsh.PMSHControlLoopDefinition:
      ...
      properties:
        ...
        elements:
          - name: org.onap.domain.pmsh.PMSH_DCAEMicroservice
            version: 1.2.3
          - name: org.onap.domain.pmsh.PMSH_MonitoringPolicyControlLoopElement
            version: 1.2.3
          - name: org.onap.domain.pmsh.PMSH_OperationalPolicyControlLoopElement
            version: 1.2.3

4.

...

1.3 New category as control loop element

New category as controlLoopElement may be introduced using which a resource can be created with category name as controlloopElement

4.

...

1.4 New category as control loop

New category as controlloop may be introduced using which a resource can be created with category name as controlLoop



4.2 New editor for ControlLoop components as a separate plugin similar to Apex editor

Image Added

4.2.1 Design of new editor plugin similar to APEX Editor

4.2.2 Design of all required controlloop components for service template

4.2.3 Reuse of SDC composition for framing controlloop

4.2.4 Reuse of SDC distribution and a verification activity

4.2.5 Integration of new editor with SDC

4.2.6 Verification of new editor as standalone GUI

4.2.7 Integrate as a new module in policy-gui