Background
Prerequisite
Design
Controller Design Studio (resource assignments)
The controller blueprint is the design time framework allowing service designer to express the what and the how to resolve resources. It uses a fully model-driven approach pushing for re-usability of artifacts.
In Casablanca, CDS solves the pre-instantiation use-case; meaning it can be used to resolve resources required to instantiate a service. The resolution can occur at VNF as well as at VF-MODULE assignment level; this correlates to the new SO Building Block flows and actions introduced in Casablanca. Resolved resources gets store in the MDSAL datasotre of SDNC, under the GENERIC-RESOURCE-API sub-tree.
The main runtime components used by CDS are the:
Service Logic Interpretor (Directed Graph engine):
A set ofself-serveDGs were introduced in Casablanca. These are fully service agnostics.
The hooks to call the self serve flow at VNF and VF-MODULE level has been introduced in the main DGs, beeingGENERIC-RESOURCE-API_vnf-topology-operation-assign.jsonandGENERIC-RESOURCE-API_vf-module-topology-operation-assign.json.
These gets called as part of the assignment step trigger by SO to SDNC, using theGENERIC-RESOURCE-API(see the requests here).
Theself-serve-*-ra-assignentDGs are the ones responsible for fetching the blueprint and the templates.- Resource accumulator:
It gets called as part of the DG execution; its goal is to resolve the resources as per as the node_template getting processed.
In Casablanca, CDS support the following source for resolution:
- SQL
- MD-SAL
- Input
- Default
- Capability: the logic to resolve the resource for that type of source is a DG, hence DG development is required to support a new capability
- Netbox (IPAM)
- Network Element Generation
There are two categories of resources, the ones that gets created; and the one that gets resolved, that were already existing. A capability as mentioned previously defines the former.
Blueprint
The blueprint is the overall JSON TOSCA based artifact expressing the what for the resource assignment process; i.e. vFW_spinup.json for this use case.
It contains a metadata section; among other fields, the following two are important as they will be used at the HEAT design time. They will allow the runtime process to identify the blueprint to use for a given service.
- template_version
- template_name
In Casablanca, for the vFW use-case, the blueprint is used to defined the various node_templates, along with their resource mappings.
node_templates
It defines the contract of the template, e.g. what resources should be resolved. It also link to the template itself. It has the following caracteristics:
- type: defines what type of template artifact it is.
- capabilities
- content: defines what is the template file name. This is the direct link to the template itself. vFW example
- mapping: defines all the resources required to be resolved for the templates. vFW example
We can have as many node template as necessary.
In the case of the vFW use case, we have 5, one for the VNF, and four for each VFC (see topology).
- VNF
- base template
- vfw
- vsn
- vpg
mapping
They belong to a node_template, and define the contract of each resources (the what) to be resolved; it's comprised of:
- name
- required / optional
- type (support complex type)
- dictionary-name
- dictionary-source
- dependencies: this allows to make sure given resources get resolved prior the resolution of the resources defining the dependency.
The dictionary fields reference to a specific data dictionary.
Template
For the pre-instantiation use-case, the template getting used are the resource accumulator templates. In Casablanca, these templates are manually created.
The resource accumulator template can be composed of the following sections:
resource-accumulator-resolved-data:
defines all the resources that can be resolved directly from the Service Logic Interpretor context. It expresses a direct mapping between the name of the resource and its value.capability-data:
defines what capability to use to create a specific resource, along with the ingredients required to invoke the capability and the output mapping.resource-accumulator-resolved-data:
defines all the resources that can be resolved directly from the Service Logic Interpretor context. It expresses a direct mapping between the name of the resource and its value.capability-data:
defines what capability to use to create a specific resource, along with the ingredients required to invoke the capability and the output mapping.
Data Dictionary
The data dictionary design time framework, part of CDS, is a standalone activity from the blueprint design. Its goal is to model the how to resolve the resource, and to make this model re-usable accross service; i.e. service-instance-id parameter will probably gets resolved always the same way, hence it can be designed once, and re-use accross all services.
As part of modelling a data dictionary entry, the following should be provided:
- name
- tags
- property
- sources
- <type of source>: (can be any type of source as long as the data to resolve already exist, else, a capability should be used; in the case of a capability, the data dictionary model would be different)
- properties
- input key mapping: resources required to perform the request/query
- output key mapping: name of the resource to be resolved mapped to the value resolved by the request/query
- key dependencies: ensure the listed dependencies are resolved prior
- <query/request>: either SQL statement or REST URI
A data dictionary entry can have multiple sources to handle resolution of the same resources in different ways.
For instance, say a resource, coming from an SQL table, is to be shared accross VF-MODULE, designer could make the resolution as part of the VNF level. Hence the data dictionary would have two sources, SQL and MDSAL. At the VNF level, process will resolve the dependency, then store it in MDSAL. So while processing VF-MODULE resolution, process can simply fetch the resolved data at VNF level from MDSAL.
Relation between blueprint, data dictionary and template
Bellow are two example using color coding to help understand the relationship.
In orange is the information regarding the template. As metnioned before, template is part of the blueprint itself, and for the blueprint to know what template to use, the name has to match.
In green is the relationship between the value resolved within the template, and how it's mapped coming from the blueprint.
In blue is the relationship between a resource mapping to a data dictionary.
In red is the relationship between the resource name to be resolved and the HEAT environment variables.
The key takeaway here is that whatever the value is for each color, it has to match all acrros. This means both right and left hand side are equivalent; it's all on the designer to express the modeling for the service.
The data dictionary design time framework, part of CDS, is a standalone activity from the blueprint design. Its goal is to model the how to resolve the resource, and to make this model re-usable accross service; i.e. service-instance-id parameter will probably gets resolved always the same way, hence it can be designed once, and re-use accross all services.
As part of modelling a data dictionary entry, the following should be provided:
- name
- tags
- property
- sources
- <type of source>: (can be any type of source as long as the data to resolve already exist, else, a capability should be used; in the case of a capability, the data dictionary model would be different)
- properties
- input key mapping: resources required to perform the request/query
- output key mapping: name of the resource to be resolved mapped to the value resolved by the request/query
- key dependencies: ensure the listed dependencies are resolved prior
- <query/request>: either SQL statement or REST URI
A data dictionary entry can have multiple sources to handle resolution of the same resources in different ways.
For instance, say a resource, coming from an SQL table, is to be shared accross VF-MODULE, designer could make the resolution as part of the VNF level. Hence the data dictionary would have two sources, SQL and MDSAL. At the VNF level, process will resolve the dependency, then store it in MDSAL. So while processing VF-MODULE resolution, process can simply fetch the resolved data at VNF level from MDSAL.
Relation between blueprint, data dictionary and template
Bellow are two example using color coding to help understand the relationship.
In orange is the information regarding the template. As metnioned before, template is part of the blueprint itself, and for the blueprint to know what template to use, the name has to match.
In green is the relationship between the value resolved within the template, and how it's mapped coming from the blueprint.
In blue is the relationship between a resource mapping to a data dictionary.
In red is the relationship between the resource name to be resolved and the HEAT environment variables.
The key takeaway here is that whatever the value is for each color, it has to match all acrros. This means both right and left hand side are equivalent; it's all on the designer to express the modeling for the service.
Topology
HEAT
Each VFC have its own HEAT template and environment file. One of the HEAT template is the base_template, it takes care of the creation of shared resources accross others VFC; i.e the protected and unprotected networks. Within the MANIFEST.json file, the base_template is identified by the boolean is_base = true, ex: https://github.com/onap/demo/blob/master/heat/vFW_NextGen/templates/MANIFEST.json#L8 This allows to correctly resolved the VFC dependency.
In Casablanca, as CDS isn't integrated within SDC, in order for the runtime to know CDS should be used for assignment, the following fields are added to the server's metadata in the HEAT template:
sdnc_model_namesdnc_model_versionsdnc_artifact_name.
They identify a Controller Blueprint that has been designed and published; ex: https://github.com/onap/demo/blob/master/heat/vFW_NextGen/templates/vfw.yaml#L200
Policy
In order to generate consistent name accross instances of the service, a naming policy has been created. The naming policy provide the recipe to generate name based on the network function type, e.g. VNF, VNC, VF-MODULE, etc...
For the vFW use case, we have a specific policy for each VFC
mysql> mysql> select * from VF_MODEL where nf_function="ONAP-FIREWALL"; +--------------------------------------+------------+--------------------------------------+--------------------------------------+---------+-------------------------+---------------------------------------+------------------------+----------------------+---------------+---------+----------+---------+-------------------------+----------------+-----------------+--------------------+--------------------+ | customization_uuid | model_yaml | invariant_uuid | uuid | version | name | naming_policy | ecomp_generated_naming | avail_zone_max_count | nf_function | nf_code | nf_type | nf_role | vendor | vendor_version | sdnc_model_name | sdnc_model_version | sdnc_artifact_name | +--------------------------------------+------------+--------------------------------------+--------------------------------------+---------+-------------------------+---------------------------------------+------------------------+----------------------+---------------+---------+----------+---------+-------------------------+----------------+-----------------+--------------------+--------------------+ | 39106d12-7629-4b6a-a6d5-b6d7a8041f00 | null | 106c91b3-c577-4658-b8c1-8bc9cd86c672 | 71256464-e388-4b7f-9b92-7c5616766465 | 1.0 | b551da0a-1fe2-489d-a486 | SDNC_Policy.ONAP_VFW_NAMING_TIMESTAMP | Y | 1 | ONAP-FIREWALL | vfw | FIREWALL | vFW | 9debd032-c839-4a61-a149 | 1.0 | vFW_spinup | 1.0.0 | vFW_vNF_Artifact | +--------------------------------------+------------+--------------------------------------+--------------------------------------+---------+-------------------------+---------------------------------------+------------------------+----------------------+---------------+---------+----------+---------+-------------------------+----------------+-----------------+--------------------+--------------------+ 1 row in set (0.00 sec)
mysql> select * from VF_MODULE_MODEL where vf_customization_uuid="39106d12-7629-4b6a-a6d5-b6d7a8041f00"; +--------------------------------------+------------+--------------------------------------+--------------------------------------+---------+----------------+-------------------------+--------------------------------+--------------------------------------+-----------------+ | customization_uuid | model_yaml | invariant_uuid | uuid | version | vf_module_type | availability_zone_count | ecomp_generated_vm_assignments | vf_customization_uuid | vf_module_label | +--------------------------------------+------------+--------------------------------------+--------------------------------------+---------+----------------+-------------------------+--------------------------------+--------------------------------------+-----------------+ | 18718327-3953-4fab-8802-aa55ecc42c29 | null | 5d0cc1d8-94f1-461c-a7be-3d18cc22da38 | c29a71ad-01fe-4f57-b64f-91e30da52274 | 1 | Expansion | NULL | NULL | 39106d12-7629-4b6a-a6d5-b6d7a8041f00 | vsn | | 4e65668c-74b0-448f-b2d2-80ed3b1afa5d | null | 986109de-26dc-4084-8ca9-7306f2bb68f3 | 3f392a6b-585e-4e1c-ad98-459a17957841 | 1 | Base | NULL | NULL | 39106d12-7629-4b6a-a6d5-b6d7a8041f00 | base_template | | 8a4361d4-18a7-4122-9fc8-554db20c03d9 | null | b95372f6-e4c3-4ee0-bb69-c343bec4d7b8 | 7bc1ace1-fe43-4b21-b5d8-60e2da5d3ada | 1 | Expansion | NULL | NULL | 39106d12-7629-4b6a-a6d5-b6d7a8041f00 | vfw | | d48b9a01-8eb9-46e0-a1d6-bd1dbe8c769d | null | b0443ba5-090d-4210-9855-5aacd960d96e | 381bf92b-d500-4ff4-a6b0-c4c875aa2df1 | 1 | Expansion | NULL | NULL | 39106d12-7629-4b6a-a6d5-b6d7a8041f00 | vpg | +--------------------------------------+------------+--------------------------------------+--------------------------------------+---------+----------------+-------------------------+--------------------------------+--------------------------------------+-----------------+ 4 rows in set (0.01 sec)
mysql> select * from VFC_MODEL where naming_policy LIKE "SDNC_Policy%";
+--------------------------------------+------------+--------------------------------------+--------------------------------------+---------+---------------------------------------+------------------------+--------------+-----------------+---------+-------------+------------------------------------------+---------------------------------------------------+-------------------+------------------------------------------------------------------------------------+---------------+---------------+
| customization_uuid | model_yaml | invariant_uuid | uuid | version | naming_policy | ecomp_generated_naming | nfc_function | nfc_naming_code | vm_type | vm_type_tag | vm_image_name | vm_flavor_name | high_availability | nfc_naming | min_instances | max_instances |
+--------------------------------------+------------+--------------------------------------+--------------------------------------+---------+---------------------------------------+------------------------+--------------+-----------------+---------+-------------+------------------------------------------+---------------------------------------------------+-------------------+------------------------------------------------------------------------------------+---------------+---------------+
| c619861e-6a66-4e9a-9d78-89327c07690d | null | 0f650273-b429-49f3-b075-6785fa2d19f2 | 8aa52209-f22f-44fb-ae44-26bfc8b1a5f9 | 1.0 | SDNC_Policy.ONAP_VSN_NAMING_TIMESTAMP | Y | vsn | vsn | vsn | vsn | PUT THE VM IMAGE NAME HERE (UBUNTU 1404) | PUT THE VM FLAVOR NAME HERE (m1.medium suggested) | NULL | {naming_policy=SDNC_Policy.ONAP_VSN_NAMING_TIMESTAMP, ecomp_generated_naming=true} | 0 | NULL |
| cd2b0be2-a3e0-40d9-baed-84aff8bf2516 | null | 5c55a913-b8a6-4e0f-9aed-71e27f383e25 | 18a784c9-4654-4698-bace-deda8673741c | 1.0 | SDNC_Policy.ONAP_VFW_NAMING_TIMESTAMP | Y | vfw | vfw | vfw | vfw | PUT THE VM IMAGE NAME HERE (UBUNTU 1404) | PUT THE VM FLAVOR NAME HERE (m1.medium suggested) | NULL | {naming_policy=SDNC_Policy.ONAP_VFW_NAMING_TIMESTAMP, ecomp_generated_naming=true} | 0 | NULL |
| d8d24f05-beab-4a2b-b1d3-7241fb0fe39b | null | 29fc467e-e69d-46da-8eaf-5c42996b7b26 | 20e5401b-1f75-4c56-b16e-c7a0c010e5c2 | 1.0 | SDNC_Policy.ONAP_VPG_NAMING_TIMESTAMP | Y | vpg | vpg | vpg | vpg | PUT THE VM IMAGE NAME HERE (UBUNTU 1404) | PUT THE VM FLAVOR NAME HERE (m1.medium suggested) | NULL | {naming_policy=SDNC_Policy.ONAP_VPG_NAMING_TIMESTAMP, ecomp_generated_naming=true} | 0 | NULL |
+--------------------------------------+------------+--------------------------------------+--------------------------------------+---------+---------------------------------------+------------------------+--------------+-----------------+---------+-------------+------------------------------------------+---------------------------------------------------+-------------------+------------------------------------------------------------------------------------+---------------+---------------+
3 rows in set (0.00 sec)
Instantiation
Assignment
SDNC requests
During the assignment process, SO building blocks are calling SDNC GENERIC-RESOURCE-API with the assignment action. This occurs as Service, VNF and VF-MODULE level. Bellow are the payloads.