Versions Compared

Key

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

Comment: This is a proposed modification to the original Self Serve Control Loop Project.  This version is in support lieu of a POC that supported the integration of Acumos / within DCAE integration.  It modifies some of the original flows moving them away from SDC and putting more of an emphasis on DCAE.  All DCAE microservice models and blueprint flows will now go through the Microservice Onboarding and Design process of DCAE.  The models and blueprints will then be distributed directly from the BPG to Policy and CLAMP.  CLAMP will be used to associate the Models to the Service.  In this new flow there will be little impact to SDC. Most of the work to implement this new flow will be done in DCAE which will be done by AT&T. This version of the project still needs to be accepted by ONAP Architecture SubCommitteefor self serve in that it suggests moving the functionality from SDC platform back into the DCAE platform. This mirrors other ONAP functionality where SDC is specifically for "Service Design" whereas other components such as CDS is for "Controller Design", Policy platform has "Policy Design", etc. In addition, it appropriately retains the responsibility for DCAE microservice design into the hands of the DCAE project team to ensure consistency across the DCAE platform.

Overview

In the Dublin Release the Control Loop team modified the basic control loop structure so that it was all based on Tosca Policy Type Models.  This made it much easier to manipulate policiesdesign and distribute DCAE Monitoring Policy Types.  It also made it so new policies TOSCA Policy Types could be developed and deployed outside the Release Cycle.  However, there were not enough resources to deliver the capability to build and distribute the new policies Policy Types through SDC as part of Service Design and Creation.

In Frankfurt we will deliver the ability to create new policies and microservices within SDC.  Add them to the CSAR file and then distribute those policies to the various control loop components (CLAMP, Policy, and DCAE)on-board and design new DCAE microservices including their TOSCA Policy Types outside the Release Cycle.

Problem Statement

Adding the The ability to create on-board and distribute new models and blueprints from SDC will enable a fully capable Self Service model to the front end of the Model Driven Control Loops that were delivered in Dublin Releasedesign new DCAE microservices has been a multi-step manual process through El Alto Release. Onboarding post release is possible, but a difficult.

Business Driver

Enable a Self Service capability to ONAP that allows for new policies on-boarding new DCAE microservices to be developed and delivered to ONAP outside of the ONAP Development cycle.

DCAE microservice designers will be able to easily design and on-board a microservice package (composed of spec.json, DataFormat.json, TOSCA Policy Type json) using a DCAE CLI into DCAE repository. They will then be able to use new DCAE Design Studio to 

Participating Companies

AT&T

Work Items

1) DCAE will make modifications to conform to the new Policy model type for the DCAE MS (onap.policies.Monitoring.)integrate new DCAE on-boarding microservice CLI and GUI Designer into the DCAE platform

2) DCAE micro service developers will on-board their mS Package (composed of a spec.json, DataFormat.json, mS Image and an optional mS Policy Model) to the DCAE Designer using the CLI that will auto-generate an instance of the Policy DCAE service component Model for use in future Control Loops. This step will also result in a simple Cloudify Blueprint generation for DCAE services. (Part #1).

NOTE: The mS Monitoring Policy Type is optional although recommended. Monitoring Policy Types can be re-usable across multiple mS if desired.

3) Blueprints generated from the BPG will be distributed to the DCAE Platform.

4) DCAE Designer will send the mS Policy Type Model to the Policy Platform using its new Lifecycle API

5) DCAE Designer will send the "Workflow" to CLAMP

6) CLAMP will retrieve the Blueprint from DCAE Inventory

7) CLAMP will retrieve any required policies Policy Types from the Policy Platform using its new Lifecycle API

8) Establish GUI and Catalog integration APIs between DCAE Design Catalog and SDC Design Catalog

Contributions

Open Questions

Impacts