4.3.4. Group Types

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:

1.1.1.1.2     Grammar

Group Types have one the following grammars:

1.1.1.2       SDC Group Type Metadata

1.1.1.3       SDC Group Type Definitions

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):

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:

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

1.1.1.3.4      org.openecomp.groups.Group

1.1.1.3.1      org.openecomp.groups.ResourceInstanceGroup