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 enabled much 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 we were unable not enough resources to deliver the capability to build and distribute the new policies through SDC as part of Service Design and Creation.

In this release 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

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, ErissonEricsson

Goals

1) SDC  DCAE will make modifications in TOSCA-Lab Blueprint Generator to conform to the new Policy DCAE service component Model.

2) SDC will need to make changes to the blueprint to generate new cloudify blueprints in the format required by DCAE that will support K8S deployment vs docker deployment (current). ONAP will be eliminating docker deployment and focusing solely on K8S deployment.

3) SDC will need to make changes to the blueprint to reference the Policy DCAE service component Policy Type from #1

4) DCAE service component developers 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 binded specifically bound to SDC service 6) If necessary, DCAE service component developers can also now use DCAE-DS to create more complex Cloudify Blueprints that can combine more than one service component together. NOTE: DCAE-DS is a consumer of the TOSCA-Lab tool. No development or testing will be done for this requirement via the Control Loop subcommittee, use case owners will be responsible for this functionality if it is a part of their Use Case flow.(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 any DCAE service component Models and blueprints they the blueprints from the BPG they wish to make available for Control Loops. SDC will distribute the CSAR as it does in Dublin with these artifacts 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