4.3.4. Group Types

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