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

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.

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) (Is this complete???)

5) Simplifying the onboarding steps for MS not specifically bound to SDC service (get better definition from Pam/Martial) (Review on 7/24)

7) When a service designer designs a new service, they will add to the service CSAR any simple DCAE micro service models (only needed for generation of complex blueprints, Determine if MS Models are needed for Frankfurt) and blueprints (both are generated by BPG) they wish to make available for Control Loops. SDC will distribute the CSAR as it does in Dublin with these artifacts 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

1) Who owns TOSCA-Lab? DCAE or SDC?

3) What is the relationship between TOSCA-Lab and DCAE-DS?

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

5) Need to review Blue Print Generator tool with Ofir and Vijay

6) What artifact generation functionality belongs to DCAE and what belongs to SDC?TODO: Ask Ofir/Ittay to attend DDF Deep Dive for Self Serve next week

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