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 easier to manipulate policies. It also made it so new policies could be developed and deployed outside the Release Cycle. However we were unable to deliver the capability to build and distribute the new policies through SDC as part of Service Design and Creation.
In this release 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 Requirement
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, Erisson
Goals
1) SDC will make modifications in TOSCA-Lab 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) (Descoped in Dublin) DCAE 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.
- Deferred to El Alto: SDC building an API to enable Integration team to automate the call to load the JSON specification during testing.
5) Simplifying the onboarding steps for MS not specifically binded 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.
7) When a service designer designs a new service, they will add to the service CSAR any DCAE service component Models and blueprints they wish to make available for Control Loops. SDC will distribute the CSAR as it does in Casablanca in Dublin with these artifacts contained within the CSAR. REPEAT
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.