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-DCAEDS 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. On-boarding a microservice post platform release is possible, but very difficult to achieve.
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/Release 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 create composite design flows, generate corresponding blueprint and make them available in DCAE inventory.
Participating Companies
AT&T
Work Items
1) DCAE will integrate new DCAE on-boarding microservice CLI and Designer GUI into the DCAE platform
2) Policy will provide tools for TOSCA Policy Type model validation for DCAE microservice owners create corresponding Policy models
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.
NOTE: The mS Policy model is optional although recommended. Monitoring Policy Types can be re-usable across multiple mS if desired.
4) Blueprints generated from the BPG will be distributed to DCAE Inventory.
5) DCAE Designer will send the mS Policy Model to the Policy Platform using its new Lifecycle API
6) DCAE Designer will send the "Workflow" to CLAMP
7) CLAMP will retrieve the Blueprint(s) from DCAE Inventory based on the "workflow" received. Separate deployment of blueprint(s).
8) CLAMP will retrieve any required Control Loop (Monitoring, Operation, Guard) Policy Types from the Policy Platform using its Lifecycle API
9) (Stretch - TBD) 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, DCAE workflow ingest, and DCAE blueprint retrieval |
| Policy | Small | Tools to support for TOSCA Policy Type validation for Policy Types |
Project Commitments
| Project | PTL | Commitment | Notes |
|---|---|---|---|
| CLAMP | COMMITTED | ||
| DCAE | COMMITTED | ||
| Policy | COMMITTED |