Comment: This is a proposed modification to the original Self Serve Control Loop Project. This version is in lieu of a POC that supported the integration of Acumos within DCAE. It modifies some of the original flows for self serve in that it suggests moving the functionality from SDC platform back into the DCAE platform. This mirrors other ONAP functionality where SDC is specifically for "Service Design" whereas other components such as CDS is for "Controller Design", Policy platform has "Policy Design", etc. In addition, it appropriately retains the responsibility for DCAE microservice design into the hands of the DCAE project team to ensure consistency across the DCAE platform.
Overview
In the Dublin Release the Control Loop team modified the basic control loop structure so that it was all based on Tosca Policy Type Models. This made it much easier to design and distribute DCAE Monitoring Policy Types. It also made it so new TOSCA Policy Types could be developed and deployed outside the Release Cycle. However, there were not enough resources to deliver the capability to build and distribute the new Policy Types through SDC as part of Service Design and Creation.
In Frankfurt we will deliver the ability to on-board and design new DCAE microservices including their TOSCA Policy Types outside the Release Cycle.
Problem Statement
The ability to on-board and design new DCAE microservices has been a multi-step manual process through El Alto Release. Onboarding post release is possible, but a difficult.
Business Driver
Enable a Self Service capability to ONAP that allows on-boarding new DCAE microservices to be developed and delivered to ONAP outside of the ONAP Development cycle.
DCAE microservice designers will be able to easily design and on-board a microservice package (composed of spec.json, DataFormat.json, TOSCA Policy Type json) using a DCAE CLI into DCAE repository. They will then be able to use new DCAE Design Studio to
Participating Companies
AT&T
Work Items
1) DCAE will integrate new DCAE on-boarding microservice CLI and GUI Designer into the DCAE platform
2) Policy will provide tools for TOSCA Policy Type model validation to for DCAE microservice designers
3) DCAE micro service developers will on-board their mS Package (composed of a spec.json, DataFormat.json, mS Image and an optional mS Policy Model) to the DCAE Designer using the CLI that will auto-generate an 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).
NOTE: The mS Monitoring Policy Type is optional although recommended. Monitoring Policy Types can be re-usable across multiple mS if desired.
34) Blueprints generated from the BPG will be distributed to the DCAE Platform.
45) DCAE Designer will send the mS Policy Type Model to the Policy Platform using its new Lifecycle API
56) DCAE Designer will send the "Workflow" to CLAMP
67) CLAMP will retrieve the Blueprint from DCAE Inventory
78) CLAMP will retrieve any required Policy Types from the Policy Platform using its new Lifecycle API
8) Establish GUI and Catalog integration APIs between DCAE Design Catalog and SDC Design Catalog
Contributions
Self Serve Proposal Differences.png
Open Questions
Impacts
| Project | Impact | Notes |
|---|---|---|
| DCAE | X-Large | Ingest of new DCAE Design Studio - code coverage requirements, security analysis, deployment K8S charts, CSIT creation, Integration test impact analysis |
| CLAMP | Large | New flows to retrieve Policy Types, blueprints |
| Policy | Small | Support for TOSCA Policy Type validation |