In lieu of new proposal, the CL subcommittee decided to deprecate this and move to using the work proposed via Self Serve Control Loops v2

Overview

In the Dublin Release the Control Loop team modified the basic control loop structure so that it was all based on Tosca Models.  This made it much easier to manipulate policies.  It also made it so new policies could be developed and deployed outside the Release Cycle.  However were not enough resources to deliver the capability to build and distribute the new policies 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)

Problem Statement

Business Requirement

CContributions

Adding the ability to create 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 Release

Business Driver

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

Participating Companies

AT&T, Samsung, Bell Canada, Ericsson

Goals

1) DCAE will make modifications in Blueprint Generator to conform to the new Policy model type for the DCAE MS (onap.policies.Monitoring.)

3) SDC will support and distribute the new policy model in Goal #1.

a) Onboard new policy types

b) Generating policy definitions in the topology template

4) DCAE micro service developers will on-board their service component using a JSON micro service specification in TOSCA-Lab that will auto-generate their own 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) (Meeting Aug 16)

5) Simplifying the onboarding steps for MS not specifically bound to SDC service (get better definition from Pam/Martial)  MOVE TO PNF PROJECT

7) When a service designer designs a new service, they will add to the service CSAR the blueprints from the BPG they wish to make available for Control Loops. SDC will distribute the CSAR as it does in Dublin with this artifact contained within the CSAR.

8) In Casablanca, the Policy SDC Service Distribution application was created. This application will now be utilized to support auto-creation of the newly on-boarded DCAE service component Policy Model when a service is distributed. Thus, when SDC distributes a new CSAR, Policy will look for new DCAE service component Policy Models not current loaded into the framework and utilize the Policy Lifecycle API to ingest these Models. NOTE: Policy will only need to do this the first time they see this service component model version. (Review on 7/24)

Contributions

Self Serve Workflows

Open Questions

4) What blueprint changes are required for El Alto? Does that require DCAE-DS to change? If so, is there backward compatibility?

6) What artifact generation functionality belongs to DCAE and what belongs to SDC?

NEED regularly occurring meetings that includes the SDC team to flush the requirements out and educate the ONAP community regarding SDC so their contributions can occur more quickly.

Impacts

The project impacted by  the Self-Serve Control Loop Use Case are: DCAE, Policy and SDC.  SDC will have the bulk of the work.

An impact assessment was done for the Dublin Release and that work can be found in the second part of the Dublin Control Loop Impacts wiki page