/
Modeling Concepts

Modeling Concepts

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.



 CBA

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

Tosca meta file is captures the model entities that compose the cba package name, version, type and searchable tags. 


AttributeR/C/OData TypeDescription
TOSCA-Meta-File-VersionRequiredStringThe attribute that holds TOSCA-Meta-File-Version.   Set to 1.0.0
CSAR-VersionRequiredString

The attribute that holds CSAR-version.   Set to 1.0

Created-ByRequiredStringThe attribute that holds the entry points
Entry-DefinitionsRequiredString

The attribute that holds the entry points file PATH to the main cba tosca definition file or non tosca script file. 

Template-NameRequiredStringThe attribute that holds the blueprint name
Template-VersionRequiredString

The attribute that holds the blueprint version 

X.Y.Z

X=Major version

Y=Minor Version

Z=Revision Version 

Ex. 1.0.0

Template-TypeRequiredString

The attribute that holds the blueprint package types. 

Valid Options: 

  • "DEFAULT"  –   .JSON file consistent of tosca based cba package that describes the package intent.
  • "KOTLIN_DSL" – .KT file consistent of tosca based cba package that describes the package intent composed using Domain Specific Language (DSL). 
  • "GENERIC_SCRIPT" – Script file consistent of NONE tosca based cba package that describes the package intent using DSL Language. 

If not specified in the tosca.meta file the default is "DEFAULT"

Template-TagsRequiredStringThe attribute that holds the blueprint package comma delimited list of Searchable attributes. 

Template Type Reference

Default Template Type

https://git.onap.org/ccsdk/cds/tree/components/model-catalog/blueprint-model/test-blueprint/capability_cli/TOSCA-Metadata/TOSCA.meta

KOTLIN_DSL Template Type

https://git.onap.org/ccsdk/cds/tree/components/model-catalog/blueprint-model/test-blueprint/resource-audit/TOSCA-Metadata/TOSCA.meta

GENERIC_SCRIPT Template Type

https://git.onap.org/ccsdk/cds/tree/components/model-catalog/blueprint-model/test-blueprint/capability_python/TOSCA-Metadata/TOSCA.meta

 Dynamic Payload

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.

request
{
  "commonHeader": {
    "originatorId": "",
    "requestId": "",
    "subRequestId": ""
  },
  "actionIdentifiers": {
    "blueprintName": "",
    "blueprintVersion": "",
    "actionName": "",
    "mode": ""
  },
  "payload": {
    "$actionName-request": {
      "$actionName-properties": {
      }
    }
  }
}
response
{
  "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

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}}/