Day 0: On-Boarding DCAE Micro Services

DCAE Micro Service On-Boarding UML

@startuml
title This is the flow for onboarding DCAE components. All components get onboarded and made available to DCAE template designer.
box "DCAE Development"
    actor Component_Developer
    entity DCAE_Comp_JSON
    participant DCAE_CLI
    
end box
box "SDC GUI" #f4c69f
    participant TOSCA_Tool as DCAE_TOSCA_Tool
    entity "MODELS/BLUEPRINTS" as MODELS
    participant SDC
    database SDC_Catalog
    end box
autonumber
loop for all DCAE Components
Component_Developer -> DCAE_Comp_JSON : Creates JSON schema\nspecifying the metadata\nrequired by this component.\nInputs\nOutputs\nConfiguration
Component_Developer <-> DCAE_CLI : Verifies the spec and deployment (if CBS/Consul are setup)
DCAE_Comp_JSON -> DCAE_TOSCA_Tool : Use TOSCA tool to\ncreate artifact.
DCAE_TOSCA_Tool -> MODELS : TOSCA Artifact created.
MODELS -> SDC : Imports into SDC\nto onboard their\nDCAE component
SDC -> SDC_Catalog : Saved into catalog
end
@enduml

TODO: change UML for terminology

DCAE Component-spec

The DCAE component specification is a JSON file that is used to describe and configure a DCAE Micro Service component.

For a complete description, examples and details of on-boarding of DCAE Micro Services, please refer to MicroServices Onboarding in ONAP.

Day 0: DCAE Design Studio Creation of Service Assurance Flows

For Beijing, the creation of Service Assurance flows are being done out-of-band using the command line tool TOSCA Lab. The service assurance flows will be pre-loaded into the SDC Catalog for Beijing. SDC is currently integrating the DCAE Design Studio as part of Beijing development.

Day 0: Importing DCAE Micro Service Policy Model

For Beijing, the DCAE Micro Service Policy Models will be pre-loaded. For development purposes, the following screen shots can be used to demonstrate how to load a model.

flow diagram/screen shots

Example of Policy Model for TCA

tosca_definitions_version: tosca_simple_yaml_1_0_0

data_types:

  policy.data.thresholds:

    properties:

      closedLoopControlName:

        type: string

        description: A UNIQUE string identifying the Closed Loop ID this event is for.

      direction:

        type: string

        constraints:

        - valid_values:

          - LESS

          - LESS_OR_EQUAL

          - GREATER

          - GREATER_OR_EQUAL

      fieldPath:

        type: string

      severity:

        type: string

        description: event severity or priority

        constraints:

        - valid_values:

          - CRITICAL

          - MAJOR

          - MINOR

          - WARNING

          - NORMAL

      thresholdValue:

        type: integer

      version:

        type: string

        description: Version for the closed loop message

node_types:

  policy.nodes.Root:

    derived_from: tosca.nodes.Root

    properties:

      policyDescription:

        required: false

        type: string

      policyName:

        required: true

        type: string

      policyScope:

        required: true

        type: string

      policyVersion:

        required: true

        type: string

  policy.nodes.cdap.tca.hi.lo.app:

    derived_from: policy.nodes.Root

    properties:

      domain:

        type: string

        constraints:

        - equal: measurementsForVfScaling

      functionalRole:

        type: string

        description: Function of the event source e.g., eNodeB, MME, PCRF

      thresholds:

        type: list

        entry_schema:

          type: policy.data.thresholds

Day 1: SDC/CLAMP Create a Control Loop in a Service

UML for CLAMP Service Assurance Configuration

@startuml
title This is the flow for designing, configuring and deploying Control Loops
actor Service_Designer
participant SDC
participant CLAMP
actor Operator
participant DCAE_SCH
participant DCAE_Deployment
participant DCAE_Inventory
participant Policy
participant DCAE_Policy_Handler
autonumber
Service_Designer -> SDC : Create/Test/Certify service, \nwith control loop DCAE flow
SDC -> CLAMP : Blueprint distribution
SDC -> DCAE_SCH : Blueprint distribution
DCAE_SCH -> DCAE_Inventory : Save blueprint
Operator -> CLAMP : Configuration of control loop
CLAMP -> Policy : Create Configuration and Operational Policies 
Policy -> DCAE_Policy_Handler : Configuration Policy
CLAMP -> DCAE_Inventory : Get DCAE Service Id based on Distributed Parameters
note left
Steps 8 and 9 are involved when there is no 
pre-deployment of control loop in DCAE
end note
CLAMP -> DCAE_Deployment : Trigger Deployment
@enduml

TODO: Update UML with correct terminology. Update UML to add SDC Service Distribution

example of policies, blueprints, api calls. etc.

Day N: Control Loop Deployment

Control Loop deployment happens when an instance of a Service is created.

TODO flow diagram

Day N: Runtime Flow of a Control Loop

The following is a control loop message flow, across DCAE, Policy and App-C. The sections afterward will describe the process for designing, configuring and instantiating this flow.

ONAP Wiki

Control Loop Sub Committee - Beijing Flow Diagrams

Day 0: On-Boarding DCAE Micro Services

DCAE Micro Service On-Boarding UML

DCAE Component-spec

Day 0: DCAE Design Studio Creation of Service Assurance Flows

Day 0: Importing DCAE Micro Service Policy Model

Example of Policy Model for TCA

Day 1: SDC/CLAMP Create a Control Loop in a Service

UML for CLAMP Service Assurance Configuration

Day N: Control Loop Deployment

Day N: Runtime Flow of a Control Loop

(1) Output of VES Collector for new PM message

(2) Output of TCA Microservice for Onset Signature

(3) Policy to App-C Request

(4) Response from App-C to Policy

(6) Output of TCA Microservice for Abate Signature

Day N: Runtime Monitoring of a Control Loop