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. 

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

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

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