1.1.1.1 Tosca Group Type Definitions
A Group Type defines logical grouping types for nodes, typically for different management purposes. Groups can effectively be viewed as logical nodes that are not part of the physical deployment topology of an application, yet can have capabilities and the ability to attach policies and interfaces that can be applied (depending on the group type) to its member nodes.
Conceptually, group definitions allow the creation of logical “membership” relationships to nodes in a service template that are not a part of the application’s explicit requirement dependencies in the topology template (i.e. those required to actually get the application deployed and running). Instead, such logical membership allows for the introduction of things such as group management and uniform application of policies (i.e., requirements that are also not bound to the application itself) to the group’s members.
1.1.1.1.1 Keynames
The Group Type is a TOSCA Entity and has the common keynames listed in section Error! Reference source not found. TOSCA Entity Schema.
In addition, the Group Type has the following recognized keynames:
...
Keyname
...
Required
...
Type
...
Description
...
attributes
...
no
...
list of
...
An optional list of attribute definitions for the Group Type.
...
properties
...
no
...
list of
...
An optional list of property definitions for the Group Type.
...
members
...
no
...
string[]
...
An optional list of one or more names of Node Types that are valid (allowed) as members of the Group Type.
Note: This can be viewed by TOSCA Orchestrators as an implied relationship from the listed members nodes to the group, but one that does not have operational lifecycle considerations. For example, if we were to name this as an explicit Relationship Type we might call this “MemberOf” (group).
...
requirements
...
no
...
list of
...
An optional sequenced list of requirement definitions for the Group Type.
...
capabilities
...
no
...
list of
...
An optional list of capability definitions for the Group Type.
...
interfaces
...
no
...
list of
...
An optional list of interface definitions supported by the Group Type.
1.1.1.1.2 Grammar
Group Types have one the following grammars:
derived_from: <parent_group_type_name> version: <version_number> metadata: description: <group_description> properties: members: [ <list_of_valid_member_types> ] requirements: capabilities: interfaces: |
...
| Table of Contents |
|---|
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
...
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”
...
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.
...
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
...
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.
...
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.
...
- 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 |
...