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) SDC  DCAE will make modifications in TOSCA-Lab Blueprint Generator to conform to the new Policy DCAE service component Policy Type Model Policy model type  for the DCAE MS (onap.policies.Monitoring.)

2) SDC  DCAE will need to make changes to the blueprint to generate new cloudify blueprints in (Single MS) 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. (DONE)

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

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

4) DCAE service component 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)

• SDC building an API to enable Integration team to automate the call to load the JSON specification during testing. (Future)

5) Simplifying the onboarding steps for MS not specifically binded to SDC service (get better definition from Pam/Martial)

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. (complex BP not supported in Frankfurt) 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.

7) When a service designer designs a new service, they will add to the service CSAR any simple DCAE service component Models and blueprints they 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.

Contributions

Self Serve Workflows

Open Questions

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

2) What are the various versions of TOSCA-Lab? How do we consolidate on one version?

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