4.3.4. Group Types
- 1 1.1.1.2 SDC Group Type Metadata
1.1.1.2 SDC Group Type Metadata
conformance level 8.0 | invariantUUID: | type: string description: Constant identifier of the resource model. Ex.: AA97B177-9383-4934-8543-0F91A7A02836 |
conformance level 8.0 | uuid: | type: string description: Versioned identifier of the resource model (this uuid is changed for every major version of the resource) Ex.: b8ff69ca-786d-479e-9f9c-217a90ee0ebc |
conformance level 8.0 | version: | type: string description: The resource version in SDC catalog. Two digit blocks separated by a dot (“.”). Ex. : “2.0” |
conformance level 8.0 | name: | type: string description: The name of the group. |
1.1.1.3 SDC Group Type Definitions
Tosca Type | Conformance level | Status |
org.openecomp. groups.VFModule | 2.0 | Defined |
org.openecomp. groups.NetworkCollection | 8.0 | Defined |
org.openecomp.groups.VfcInstanceGroup | 8.0 | Defined |
org.openecomp.groups.Group | Future | Defined |
org.openecomp.groups.ResourceInstanceGroup | Future | Defined |
1.1.1.3.1 org.openecomp. groups.VFModule
A VF can be divided to several modules. There will be a base module, which consists the essential part of the VF. There might also be expansion modules associated with that base module .
The Expansion modules can give additional functionality that can be deployed or not.
The VF or Service Designer defines the module by assigning values to its properties.
The module properties are (note that these properties will be available only for VFs / Services creaed / modified in SDC 1702 and above):
Field name | Type | Mandatory | Description |
vf_module_type | String | Yes | Whether this is base module or expansion. Valid values: [Base, Expansion] Ex: “Base” |
vf_module_label | String | Yes | The label is the middle part (the free text) of the module name. the default value for this field is the HEAT filename of theVF Module’s HeatStack Ex: “base_ adtran_pmaa_heat_04” |
min_vf_module_instances | integer | Yes | The minimum number of orchestrated instances allowed of this VF-Module. Default value: for base is 1, for non-base is 0 Ex. “2” |
max_vf_module_instances | integer | No | The maximum number of orchestrated instances allowed of this VF-Module. Default value: for base is 1 Ex. “3” |
initial_count | integer | Yes | The initial count of orchestrated instances of the VF-Module. The value must be in the range between min_vf_module_instances and max_vf_module_instances. Default value: for base is 1, for non-base is 0 Ex. “1” |
vf_module_description | String | No | Description of the VF-modules contents and purpose This value is provided by user. Might be empty. Ex. “Base module for vADTRAN” |
volume_group | Boolean | Yes | An indication whether this VF Module includes a volume definition |
group_naming | org.openecomp.datatypes.Naming | No | The naming policy (name in policy engine) to be used in runtime for generating the instance name of the vf_module Note: This property is supported only from conformance level 8.0 (Release 1806) |
1.1.1.3.1.1 Syntax
The VF Module information can be found in the “groups” section in the VF TOSCA. The group type of the VF Module is “org.openecomp.groups.VfModule”
Note that in the “groups” section there might be other groups as well that do not represent VF Module.
Example:
groups:
vadtran_Demo..base_adtran_pmaa_heat_04..module-0:
type: org.openecomp.groups.VfModule
metadata:
vfModuleModelName: vadtran_Demo..base_adtran_pmaa_heat_04..module-0
vfModuleModelInvariantUUID: d84f61c9-160a-44b6-a008-6caadbb6c612
vfModuleModelUUID: fbf41c77-a7ee-4203-ad6c-eeb8a4ad7178
vfModuleModelVersion: '1'
properties:
vf_module_type: Base
vf_module_description: This is a base module for vADTRAN
volume_group: false
vf_module_label: base_adtran_pmaa_heat_04
min_vf_module_instances: 1
max_vf_module_instances: 1
initial_count: 1
1.1.1.3.1.2 Usage
The properties defined above are added by default for every VF Module created. The default values for the properties are defined in the table above.
In the SDC Catalog, the properties can be viewed in the “Deployment” view. The designer can update the values of these properties.
Once the TOSCA of the VF is generated, the values will be provided in the specific vf module in the “groups” section.
1.1.1.3.1.3 VF Module in Service Level and vfModuleCustomizationUUID
As described in 3.4, a VF can be composed from VF Modules. Those VF Modules have some properties that can also be updated in the service level.
When making a change to the VF module in the service Level, the changes do not apply on the VF model. The changes apply only in the service level.
Since the changes apply only in the service level, the VF Modules must be reflected in the service TOSCA (in 1610, the VF Modules were described in the VF TOSCA only).
Since there might be more than one VF of same type in the service, every VF Module in the service level will have vfModuleCustomizationUUID. The vfModuleCustomizationUUID is regenerated for every change in the property values or the ENV file that is attached to it.
The key of the VF Module in the service level will be the VF instance name appended to the VF Module name: <VF instance name>..<VF Module name>
1.1.1.3.1.3.1 Syntax
The VF Module information can be found in the “groups” section in the Service TOSCA. The group type of the VF Module is “org.openecomp.groups.VfModule”. The vfModuleCustomizationUUID is one of the vf module metadata fields.
Note that in the “groups” section there might be other groups as well that do not represent VF Module.
Example:
groups:
myVadtran..vadtran_Demo..base_adtran_pmaa_heat_04..module-0:
type: org.openecomp.groups.VfModule
metadata:
vfModuleModelName: vadtran_Demo..base_adtran_pmaa_heat_04..module-0
vfModuleModelInvariantUUID: d84f61c9-160a-44b6-a008-6caadbb6c612
vfModuleCustomizationUUID: b020ed1e-4bc7-4fc0-ba7e-cc7af6da7ffc
vfModuleModelUUID: fbf41c77-a7ee-4203-ad6c-eeb8a4ad7178
vfModuleModelVersion: '1'
properties:
vf_module_type: Base
vf_module_description: This is a base module for vADTRAN
volume_group: false
vf_module_label: base_adtran_pmaa_heat_04
min_vf_module_instances: 1
max_vf_module_instances: 1
initial_count: 1
1.1.1.3.1.3.2 Usage
The vfModuleCustomizationUUID can be used to identify a specific VF Module in the service and send MSO the specific configuration for it.
1.1.1.3.2 org.openecomp. groups.NetworkCollection
Group with type NetworkCollection allows a designer to specify collection of a tenant l3- networks (N instances) with the identical attributes along with a quantity value. MSO will obtain unique network name and VPN Binding assignments for each l3-network in the collection.
TOSCA definition:
group_types: org.openecomp.groups.NetworkCollection: derived_from: tosca.groups.Root description: groups l3-networks in network collection properties: network_collection_function: type: string required: true description: network collection function network_collection_description: type: string required: true description: network collection description, free format text |
1.1.1.3.3 org.openecomp.groups.VfcInstanceGroup
generated by Heat-To-Tosca
Depending on the particular VNF design, every VM may require attachment to the same set of virtual networks, or it is possible that some of the VMs may be designated to attach to different groups of virtual networks.
To manage the relationships of VMs to specific sub-interfaces, such as a VLAN Network Receptor, VNFC Instance Groups will be defined as part of the parent infrastructure service model that provides a VLAN Assignment capability. When VMs are instantiated, it will be necessary to identify the VNFC type that is associated with the VM, along with the VNFC Instance Group that the VNFC belongs to.
VFC Instance Group is based on Subinterface capable VFC(s) connected to same set of subinterface networks.
VFC port, to which the sub-interfaces are to be created will have boolean property (subinterface_indicator) to indicate this ability.
Subinterface capable VFC should be indicated by new capability or requirement type, that may be exposed on VNF level.
subinterface_link:
capability: tosca.capabilities.network.Linkable
relationship: tosca.relationships.network.LinksTo
VFCs, defined as a members in the VFC Instance Group may be with different naming-codes (e.g. “SSC” and “MSC”) on same group.
VFCs, defined as a members in the VFC Instance Group have same
parent port network role (18.06 release restriction, there are no use cases with a number of parent port network roles on same VFC Instance Group)
subinterface network role (criteria VFC Group is generated)
network collection function (defined by designer)
VFC instance group function (defined by designer)
VF Module (group) and VFC instance group may have same VFC as a member
group_types: org.openecomp.groups.VfcInstanceGroup derived_from: tosca.groups.Root description: groups VFCs with same subinterface role properties: vfc_instance_group_function: type: string required: true description: function of this VFC group vfc_parent_port_role type: string required: true description: common role of parent ports of VFCs in this group network_collection_function: type: string required: true description: network collection function assigned to this group subinterface_role: type: string required: true description: common role of subinterfaces of VFCs in this group, criteria the group is created capabilities: vlan_assignment: type: org.openecomp.capabilities.VLANAssignment properties: vfc_instance_group_reference: type:string |
1.1.1.3.4 org.openecomp.groups.Group
org.openecomp.groups.Group: derived_from: tosca.groups.Root properties: | ||
type: | type: string description: The type of the nodes supported by group. Ex. “VNF”, “VNFC” required: false | |
role: | type: string description: The role of the group. Ex.” Highly Available”, “Cluster”, “GEOR”, “Quorum”, ”Scaling”, “Deployment” required: false | |
function: | type: string description: The function of the groups. Ex. “GEO-ACTIVE-ACTIVE”, GEO-ACTIVE-STANDBY”, “SITE-RESILIENT”, “ROUND-ROBIN-QUORUM” required: false |
1.1.1.3.1 org.openecomp.groups.ResourceInstanceGroup
org.openecomp.groups.ResourceInstanceGroup: derived_from: org.openecomp.groups.Group properties: | ||
description: | type: string description: Description of the group. Ex. “VE FLEX”, “BVoIP ASR cluster” required: false | |
level: | type: string description: The level of the resources grouping for the redundancy or resiliency. Ex. “Location”, “Zone”, “Cloud-region” required: false |