Modeling Concepts
- Alexis de Talhouët
- Jakob Krieg
- Steve Alphonse Siani (Deactivated)
Migrated to ReadTheDocs
Further updates must be done in the corresponding RST file(s) by following the build process for documentation.
https://docs.onap.org/projects/onap-ccsdk-cds/en/latest/modelingconcepts/index.html
2020-08-11, Jakob Krieg
CDS is a framework to automate the resolution of resources for instantiation and any config provisioning operation, such as day0, day1 or day2 configuration.
CDS has a both design time and run time activities; during design time, Designer can define what actions are required for a given service, along with anything comprising the action. The design produce a CBA Package . Its content is driven from a catalog of reusable data dictionary and component, delivering a reusable and simplified self service experience.
CDS modelling is mainly based on TOSCA standard, using JSON as reprensentation.
Most of the TOSCA modeled entity presented in the bellow documentation can be found here.
Controller Blueprint Archive (.cba)
The Controller Blueprint Archive is the overall service design, fully model-driven, intent based package needed for provisioning and configuration management automation.
The CBA is .zip file, comprised of the following folder structure, the files may vary:
├── Definitions │ ├── blueprint.json Overall TOSCA service template (workflow + node_template) │ ├── artifact_types.json (generated by enrichment) │ ├── data_types.json (generated by enrichment) │ ├── policy_types.json (generated by enrichment) │ ├── node_types.json (generated by enrichment) │ ├── relationship_types.json (generated by enrichment) │ ├── resources_definition_types.json (generated by enrichment) | └── *-mapping.json One per Template ├── Environments Contains *.properties files as required by the service ├── Plans Contains Directed Graph ├── Tests Contains uat.yaml file for testing cba actions within a cba package ├── Scripts Contains scripts │ ├── python Python scripts │ └── kotlin Kotlin scripts ├── TOSCA-Metadata │ └── TOSCA.meta Meta-data of overall package └── Templates Contains combination of mapping and template
To process a CBA for any service we need to enrich it first. This will gather all the node-type, data-type, artifact-type, data-dictionary definitions provided in the blueprint.json.
Tosca Meta
Tosca meta file is captures the model entities that compose the cba package name, version, type and searchable tags.
Attribute | R/C/O | Data Type | Description |
---|---|---|---|
TOSCA-Meta-File-Version | Required | String | The attribute that holds TOSCA-Meta-File-Version. Set to 1.0.0 |
CSAR-Version | Required | String | The attribute that holds CSAR-version. Set to 1.0 |
Created-By | Required | String | The attribute that holds the entry points |
Entry-Definitions | Required | String | The attribute that holds the entry points file PATH to the main cba tosca definition file or non tosca script file. |
Template-Name | Required | String | The attribute that holds the blueprint name |
Template-Version | Required | String | The attribute that holds the blueprint version X.Y.Z X=Major version Y=Minor Version Z=Revision Version Ex. 1.0.0 |
Template-Type | Required | String | The attribute that holds the blueprint package types. Valid Options:
If not specified in the tosca.meta file the default is "DEFAULT" |
Template-Tags | Required | String | The attribute that holds the blueprint package comma delimited list of Searchable attributes. |
Template Type Reference
Default Template Type
KOTLIN_DSL Template Type
GENERIC_SCRIPT Template Type
Dynamic payload
One of the most important API provided by the run time is to execute a CBA Package.
The nature of this API request and response is model driven and dynamic.
Here is how the a generic request and response look like.
{ "commonHeader": { "originatorId": "", "requestId": "", "subRequestId": "" }, "actionIdentifiers": { "blueprintName": "", "blueprintVersion": "", "actionName": "", "mode": "" }, "payload": { "$actionName-request": { "$actionName-properties": { } } } }
{ "commonHeader": { "originatorId": "", "requestId": "", "subRequestId": "" }, "actionIdentifiers": { "blueprintName": "", "blueprintVersion": "", "actionName": "", "mode": "" }, "payload": { "$actionName-response": { } } }
The actionName
, under the actionIdentifiers
refers to the name of a Workflow (see Modeling Concepts#workflow)
The content of the payload
is what is fully dynamic / model driven.
The first top level element will always be either $actionName-request
for a request or $actionName-response
for a response.
Then the content within this element is fully based on the workflow inputs and outputs.
During the Enrichment, CDS will aggregate all the resources defined to be resolved as input, within mapping definition files, as data-type, that will then be use as type of an input called $actionName-properties
.
Enrichment
The idea is that the CBA is a self-sufficient package, hence requires all the various types definition its using.
Reason for this is the types its using might evolve. In order for the CBA to be bounded to the version it has been using when it has been designed, these types are embedded in the CBA, so if they change, the CBA is not affected.
The enrichment process will complete the package by providing all the definition of types used:
- gather all the node-type used and put them into a
node_types.json
file - gather all the data-type used and put them into a
data_types.json
file - gather all the artifact-type used and put them into a
artifact_types.json
file - gather all the data dictionary definitions used from within the mapping files and put them into a
resources_definition_types.json
file
Before uploading a CBA, it must be enriched. If your package is already enrich, you do not need to perform enrichment again.
The enrichment can be run using REST API, and required the .zip file as input. It will return an enriched-cba.zip file.
curl -X POST \ 'http://{{ip}}:{{cds-designtime}}/