...

Unsurprisingly, to define a Control Loop Type in TOSCA, we must first define a number of Control Loop related concepts that we can use in all control loops.

1 Standard TOSCA Service Template Concepts for Control Loops

These concepts are the base concepts available to users who write definitions for control loops in TOSCA. TOSCA control loop definitions are written using these concepts.

1.1 Fundamental TOSCA Concepts for Control Loops

The following TOSCA concepts are the fundamental concepts in a TOSCA Service Template for defining control loops.

...

The TOSCA concepts above may be declared in the TOSCA Service Template of a control loop. If the concepts already exist in the Design Time Catalogue or the Runtime Inventory, they may be omitted from a TOSCA service template that defines a control loop type.

The start_phase is a value indicating the start phase in which this control loop element will be started, the first start phase is zero. Control Loop Elements are started in their start_phase order and stopped in reverse start phase order. Control Loop Elements with the same start phase are started and stopped simultaneously

The Yaml file that holds the  Definition of TOSCA fundamental Control Loop Types is available in Github and is the canonical definition of the Control Loop concepts.

1.2 TOSCA Concepts for Control Loop Elements delivered by ONAP

DrawiobordertruediagramNameStandard_CLEA Control Loop Definition is made up of several components, those which represent applications, those which represent dynamic config schemas, and the actual node_templates which makes up the loop itself.

Applications can be a DCAE microservice, an operational policy, or any other application as long as it can be modeled, and the targeted ecosystem to has a participant client waiting for the event distributions from CLAMP via DMaaP Message Router.

Dynamic config on the other hand can be a monitoring policy, or any other resource that provides config to parts of the loop, can be updated after the run time phase has started and is supported by the components hosting the applications in the control loop.

A Control Loop Component that can be part of a control loop, it defines the components that partake in a control loop, and are implemented at run time by participants. The control loop component definition is truly dynamic and, as long as the participant that the control loop component definition relates to understands its definition, it can be anything. However, we have designed a base control loop component attribute that's generic and that can act as a good starting point.

The loop definition is explicit in the node_templates within the topology_template,  a Control Loop node template is specified and any node template specified in the Control Loop node template is part of the control loop managed by CLAMP.

1 Standard TOSCA Service Template Concepts for Control Loops

These concepts are the base concepts available to users who write definitions for control loops in TOSCA. TOSCA control loop definitions are written using these concepts.

1.1 Fundamental TOSCA Concepts for Control Loops

The following TOSCA concepts are the fundamental concepts in a TOSCA Service Template for defining control loops.

...

...

The Policy Participant runs Policy Control Loop Elements. Each Policy Control Loop Element manages the deployment of the policy specified in the Policy Control Loop Element definition. The Yaml file that holds the  <INSERT LINK HERE WHEN IT IS MERGED> is available in Github and is the canonical definition of the Policy Control Loop Element type. For a description of the Policy Control Loop Element and Policy Participant, please see The CLAMP Policy Framework Participant page.

1.2.2 HTTP Control Loop Element

The HTTP Participant runs HTTP Control Loop Elements. Each HTTP Control Loop Element manages REST communication towards a REST endpoint using the REST calls a user has specified in the configuration of the HTTP Control Loop Element

The TOSCA concepts above may be declared in the TOSCA Service Template of a control loop. If the concepts already exist in the Design Time Catalogue or the Runtime Inventory, they may be omitted from a TOSCA service template that defines a control loop type.

The start_phase is a value indicating the start phase in which this control loop element will be started, the first start phase is zero. Control Loop Elements are started in their start_phase order and stopped in reverse start phase order. Control Loop Elements with the same start phase are started and stopped simultaneously

The Yaml file that holds the  Definition of TOSCA fundamental Control Loop Types is available in Github and is the canonical definition of the Control Loop concepts.

1.2 TOSCA Concepts for Control Loop Elements delivered by ONAP

1.2.1 Policy Control Loop Element

The Policy Participant runs Policy Control Loop Elements. Each Policy Control Loop Element manages the deployment of the policy specified in the Policy Control Loop Element definition. The Yaml file that holds the  <INSERT LINK HERE WHEN IT IS MERGED> is available in Github and is the canonical definition of the HTTP Policy Control Loop Element type. For a description of the HTTP Policy Control Loop Element and HTTP Policy Participant, please see The CLAMP HTTP Policy Framework Participant page.

1.2.

...

2 HTTP Control Loop Element

The Kubernetes The HTTP Participant runs Kubernetes runs HTTP Control Loop Elements. Each Kubernetes Each HTTP Control Loop Element manages a Kubernetes microservice using Helm. The user defines the Helm chart for the Kubernetes microservice as well as other properties that the microservice requires in order to executeREST communication towards a REST endpoint using the REST calls a user has specified in the configuration of the HTTP Control Loop Element. The Yaml file that holds the  <INSERT LINK HERE WHEN IT IS MERGED> is available in Github and is the canonical definition of the Kubernetes the HTTP Control Loop Element type. For a description of the Kubernetes the HTTP Control Loop Element and Kubernetes and HTTP Participant, please see see The CLAMP Kubernetes HTTP Participant page.

1.2.

...

3 Kubernetes Control Loop Element

The CDS The Kubernetes Participant runs CDS runs Kubernetes Control Loop Elements. Each CDS Each Kubernetes Control Loop Element manages the deployment of the CDS blueprint specified in the CDS Control Loop Element definitiona Kubernetes microservice using Helm. The user defines the Helm chart for the Kubernetes microservice as well as other properties that the microservice requires in order to execute. The Yaml file that holds the  <INSERT LINK HERE WHEN IT IS MERGED> is available in Github and is the canonical definition of the CDS the Kubernetes Control Loop Element type. For a description of the CDS the Kubernetes Control Loop Element and CDS and Kubernetes Participant, please see see The CLAMP CDS Kubernetes Participant page.

1.2.

...

4 CDS Control Loop Element

The

...

CDS Participant

...

runs CDS Control Loop Elements.

...

Each CDS Control Loop Element manages

...

the deployment of the CDS blueprint specified in the CDS Control Loop Element definition. The Yaml file that holds the  <INSERT LINK HERE WHEN IT IS MERGED> is available in Github and is the canonical definition of

...

the CDS Control Loop Element type. For a description of

...

the CDS Control Loop Element

...

and CDS Participant, please

...

see The CLAMP

...

CDS Participant page.

2 Common and Instance Specific Properties

Properties are used to define the configuration for Control Loops and Control Loop Elements. At design time, the types, constraints, and descriptions of the properties are specified. The values for properties are specified in the CLAMP GUI at runtime. TOSCA provides support fir defining properties, see Section 3.6.10: TOSCA Property Definition in the TOSCA documentation.

2.1 Terminology for Properties

Property: Metadata defined in TOSCA that is associated with a Control Loop, a Control Loop Element, or a Participant.

TOSCA Property Type: The TOSCA definition of the type of a property. A property can have a generic type such as string or integer or can have a user defined TOSCA data type.

TOSCA Property Value: The value of a Property Type. Property values are assigned at run time in CLAMP.

Common Property Type: Property Types that apply to all instances of a Control Loop Type.

Common Property Value: The value of a Property Type. It is assigned at run time once for all instances of a Control Loop Type.

...

1.2.5 DCAE Participant

The DCAE Participant runs DCAE Control Loop Elements. Each DCAE Control Loop Element manages a DCAE microservice on DCAE. The user defines the DCAE blueprint for the DCAE microservice as well as other properties that the microservice requires in order to execute. The Yaml file that holds the  <INSERT LINK HERE WHEN IT IS MERGED> is available in Github and is the canonical definition of the DCAE Control Loop Element type. For a description of the DCAE Control Loop Element and DCAE Participant, please see The CLAMP DCAE Participant page.

2 Common and Instance Specific Properties

Properties are used to define the configuration for Control Loops and Control Loop Elements. At design time, the types, constraints, and descriptions of the properties are specified. The values for properties are specified in the CLAMP GUI at runtime. TOSCA provides support fir defining properties, see Section 3.6.10: TOSCA Property Definition in the TOSCA documentation.

2.1 Terminology for Properties

Property: Metadata defined in TOSCA that is associated with a Control Loop, a Control Loop Element, or a Participant.

TOSCA Property Type: The TOSCA definition of the type of a property. A property can have a generic type such as string or integer or can have a user defined TOSCA data type.

TOSCA Property Value: The value of a Property Type. Property values are assigned at run time in CLAMP.

Common Property Type: Property Types that apply to an individual instance all instances of a Control Loop Type.

Instance Specific Common Property Value: The value of a Property Type that applies . It is assigned at run time once for all instances of a Control Loop Type.

Instance Specific Property Type: Property Types that apply to an individual instance of a Control Loop Type.

Instance Specific Property Value: The value of a Property Type that applies to an individual instance of a Control Loop Type. The value is assigned at run time for each control loop instance.

...

Instance Specific  properties apply to individual instances of a Control Loop and/or Control Loop Element and must be set individually for Control Loop and Control Loop Element instance. Properties are instance specific by default, but can be identified by a special metadata flag in Control Loop and Control Loop Element definitions. For example, the chart parameter on a Policy Kubernetes Control Loop Element has a different value for evey every instance of a Policy Kubernetes Control Loop Element, so it can be defined as shown below in the  <INSERT LINK HERE WHEN IT IS MERGED>  yaml file.

# Definition that omits the common flag metadata
policyType:
  type: onap.datatypes.ToscaConceptIdentifier
  required: true

# Definition that specifies the common flag metadata
policyType:
  type: onap.datatypes.ToscaConceptIdentifier
  required: true
  metadata:
    common: false

The "common: false" value in the metadata of the policyId property identifies that property as being an instance specific property. This property will be set on the CLAMP GUI during control loop instantiation.

A Control Loop Definition is made up of several components, those which represent applications, those which represent dynamic config schemas, and the actual node_templates which makes up the loop itself.

Applications can be a DCAE microservice, an operational policy, or any other application as long as it can be modeled, and the targeted ecosystem to has a participant client waiting for the event distributions from CLAMP via DMaaP Message Router.

Dynamic config on the other hand can be a monitoring policy, or any other resource that provides config to parts of the loop, can be updated after the run time phase has started and is supported by the components hosting the applications in the control loop.

1. Control Loop TOSCA file definition

1.1 Control Loop Component Definition 

A Control Loop Component that can be part of a control loop, it defines the components that partake in a control loop, and are implemented at run time by participants. The control loop component definition is truly dynamic and, as long as the participant that the control loop component definition relates to understands its definition, it can be anything. However, we have designed a base control loop component attribute that's generic and that can act as a good starting point.

node_types:
  org.onap.CL_Component:
    properties:
      component_name:
        type: string
        description: Human readable name for the component.
        required: true
      provider:
        type: string
        description: Provider of the component and of the descriptor.
        required: true
      component_version:
        type: string
        description: Software version of the component.
        required: true
      resource_id:
        type: string
        description: >The ID of the resource, 
          should be provided if the resource was uploaded to the entity's inventory already.
        required: false
      resource_content:
        type: string
        description: the contents of the component resource, to be uploaded during commssioning phase of loop.
        required: false
      monitoring_policy:
        type: string
        description: A reference to the monitoring policy if applicable.
        required: false
    version: 0.0.1
    derived_from: tosca.nodes.Root

1.2 Loop Definition

The loop definition is explicit in the node_templates within the topology_template,  a Control Loop node template is specified and any node template specified in the Control Loop node template is part of the control loop managed by CLAMP.

tosca_definitions_version: tosca_simple_yaml_1_3
data_types:
  onap.datatypes.ToscaConceptIdentifier:
    derived_from: tosca.datatypes.Root
    properties:
      name:
        type: string
        required: true
      version:
        type: string
        required: true
node_types:
  org.onap.policy.clamp.controlloop.Participant:
    version: 1.0.1
    derived_from: tosca.nodetypes.Root
    properties:
      provider:
        type: string
        requred: false
  org.onap.policy.clamp.controlloop.ControlLoopElement:
    version: 1.0.1
    derived_from: tosca.nodetypes.Root
    properties:
      provider:
        type: string
        requred: false
      participant_id:
        type: onap.datatypes.ToscaConceptIdentifier
        requred: true
  org.onap.policy.clamp.controlloop.ControlLoop:
    version: 1.0.1
    derived_from: tosca.nodetypes.Root
    properties:
      provider:
        type: string
        requred: false
      elements:
        type: list
        required: true
        entry_schema:
          type: onap.datatypes.ToscaConceptIdentifier
  org.onap.policy.clamp.controlloop.DCAEMicroserviceControlLoopElement:
    version: 1.0.1
    derived_from: org.onap.policy.clamp.controlloop.ControlLoopElement
    properties:
      dcae_blueprint_id:
        type: onap.datatypes.ToscaConceptIdentifier
        requred: true
  org.onap.policy.clamp.controlloop.PolicyTypeControlLoopElement:
    version: 1.0.1
    derived_from: org.onap.policy.clamp.controlloop.ControlLoopElement
    properties:
      policy_type_id:
        type: onap.datatypes.ToscaConceptIdentifier
        requred: true
  org.onap.policy.clamp.controlloop.CDSControlLoopElement:
    version: 1.0.1
    derived_from: org.onap.policy.clamp.controlloop.ControlLoopElement
    properties:
      cds_blueprint_id:
        type: onap.datatypes.ToscaConceptIdentifier
        requred: true
topology_template:
  node_templates:
    org.onap.dcae.controlloop.DCAEMicroserviceControlLoopParticipant:
      version: 2.3.4
      type: org.onap.policy.clamp.controlloop.Participant
      type_version: 1.0.1
      description: Participant for DCAE microservices
      properties:
        provider: ONAP
    org.onap.policy.controlloop.MonitoringPolicyControlLoopParticipant:
      version: 2.3.1
      type: org.onap.policy.clamp.controlloop.Participant
      type_version: 1.0.1
      description: Participant for DCAE microservices
      properties:
        provider: ONAP
    org.onap.policy.controlloop.OperationalPolicyControlLoopParticipant:
      version: 3.2.1
      type: org.onap.policy.clamp.controlloop.Participant
      type_version: 1.0.1
      description: Participant for DCAE microservices
      properties:
        provider: ONAP
    org.onap.ccsdk.cds.controlloop.CdsControlLoopParticipant:
      version: 2.2.1
      type: org.onap.policy.clamp.controlloop.Participant
      type_version: 1.0.1
      description: Participant for DCAE microservices
      properties:
        provider: ONAP
    org.onap.domain.pmsh.PMSH_DCAEMicroservice:
      version: 1.2.3
      type: org.onap.policy.clamp.controlloop.DCAEMicroserviceControlLoopElement
      type_version: 1.0.0
      description: Control loop element for the DCAE microservice for Performance Management Subscription Handling
      properties:
        provider: Ericsson
        participant_id:
          name: org.onap.dcae.controlloop.DCAEMicroserviceControlLoopParticipant
          version: 2.3.4
        dcae_blueprint_id:
          name: org.onap.dcae.blueprints.PMSHBlueprint
          version: 1.0.0
    org.onap.domain.pmsh.PMSH_MonitoringPolicyControlLoopElement:
      version: 1.2.3
      type: org.onap.policy.clamp.controlloop.PolicyTypeControlLoopElement
      type_version: 1.0.0
      description: Control loop element for the monitoring policy for Performance Management Subscription Handling
      properties:
        provider: Ericsson
        participant_id:
          name: org.onap.policy.controlloop.PolicyControlLoopParticipant
          version: 2.3.1
        policy_type_id:
          name: onap.policies.monitoring.pm-subscription-handler
          version: 1.0.0
    org.onap.domain.pmsh.PMSH_OperationalPolicyControlLoopElement:
      version: 1.2.3
      type: org.onap.policy.clamp.controlloop.PolicyTypeControlLoopElement
      type_version: 1.0.0
      description: Control loop element for the operational policy for Performance Management Subscription Handling
      properties:
        provider: Ericsson
        participant_id:
          name: org.onap.policy.controlloop.PolicyControlLoopParticipant
          version: 2.3.1
        policy_type_id:
          name: onap.policies.operational.pm-subscription-handler
          version: 1.0.0
    org.onap.domain.pmsh.PMSH_CDS_ControlLoopElement:
      version: 1.2.3
      type: org.onap.policy.clamp.controlloop.ControlLoopElement
      type_version: 1.0.0
      description: Control loop element for CDS for Performance Management Subscription Handling
      properties:
        provider: Ericsson
        participant_Id:
          name: org.onap.ccsdk.cds.controlloop.CdsControlLoopParticipant
          version: 3.2.1
        cds_blueprint_id:
          name: org.onap.ccsdk.cds.PMSHCdsBlueprint
          version: 1.0.0
    org.onap.domain.pmsh.PMSHControlLoopDefinition:
      version: 1.2.3
      type: org.onap.policy.clamp.controlloop.ControlLoop
      type_version: 1.0.0
      description: Control loop for Performance Management Subscription Handling
      properties:
        provider: Ericsson
        elements:
        - name: org.onap.domain.pmsh.PMSH_DCAEMicroservice
          version: 1.2.3
        - name: org.onap.domain.pmsh.PMSH_MonitoringPolicyControlLoopElement
          version: 1.2.3
        - name: org.onap.domain.pmsh.PMSH_OperationalPolicyControlLoopElement
          version: 1.2.3
        - name: org.onap.domain.pmsh.PMSH_CDS_ControlLoopElement
          version: 1.2.3
 that omits the common flag metadata
chart:
  type: org.onap.datatypes.policy.clamp.controlloop.kubernetesControlLoopElement.Chart
  typeVersion: 1.0.0
  description: The helm chart for the microservice
  required: true

# Definition that specifies the common flag metadata
chart:
  type: org.onap.datatypes.policy.clamp.controlloop.kubernetesControlLoopElement.Chart
  typeVersion: 1.0.0
  description: The helm chart for the microservice
  required: true

  metadata:
    common: false

The "common: false" value in the metadata of the chart property identifies that property as being an instance specific property. This property will be set on the CLAMP GUI during control loop instantiation.

2.2: Modelling from TOSCA to Commissioned Data in Run Time Inventory

...