Control Loop Sub Committee - Beijing Flow Diagrams
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.
(1) Output of VES Collector for new PM message
{
"event": {
"commonEventHeader": {
"startEpochMicrosec": 1500584201765465,
"sourceId": "Dummy VM UUID - No Metadata available",
"eventId": "11",
"reportingEntityId": "No UUID available",
"internalHeaderFields": {
"collectorTimeStamp": "Thu, 07 20 2017 08:56:52 GMT"
},
"eventType": "HTTP request rate",
"priority": "Normal",
"version": 1.2,
"reportingEntityName": "fwll",
"sequence": 11,
"domain": "measurementsForVfScaling",
"lastEpochMicrosec": 1500584212017216,
"eventName": "vnfScalingMeasurement",
"sourceName": "Dummy VM name - No Metadata available"
},
"measurementsForVfScalingFields": {
"cpuUsageArray": [{
"percentUsage": 0,
"cpuIdentifier": "cpu1",
"cpuIdle": 100,
"cpuUsageSystem": 0,
"cpuUsageUser": 0
}],
"measurementInterval": 10,
"requestRate": 7832,
"vNicUsageArray": [{
"transmittedOctetsDelta": 5680,
"receivedTotalPacketsDelta": 14,
"vNicIdentifier": "eth0",
"valuesAreSuspect": "true",
"transmittedTotalPacketsDelta": 31,
"receivedOctetsDelta": 1332
}],
"measurementsForVfScalingVersion": 2.1
}
}
}(2) Output of TCA Microservice for Onset Signature
{
"closedLoopControlName": "ControlLoop-vCPE-48f0c2c3-a172-4192-9ae3-052274181b6e",
"version": "1.0.2",
"requestID": "a20e2073-30b1-4357-893b-f5ed57b66ef0",
"closedLoopAlarmStart": 1478189220547,
"closedLoopEventClient": "DCAE_INSTANCE_ID.dcae-tca",
"target_type": "VNF",
"target": "generic-vnf.vnf-name",
"AAI": {
"generic-vnf.vnf-name" : "vCPE_Infrastructure_vGMUX_demo_app"
},
"from": "DCAE",
"policyScope": "DCAE",
"policyName": "DCAE.Config_tca-hi-lo",
"policyVersion": "v0.0.1",
"closedLoopEventStatus": "ONSET"
}(3) Policy to App-C Request
{
"body": {
"input": {
"common-header": {
"timestamp": "2017-08-25T21:06:23.037Z",
"api-ver": "2.00",
"originator-id": "a20e2073-30b1-4357-893b-f5ed57b66ef0",
"request-id": "a20e2073-30b1-4357-893b-f5ed57b66ef0",
"sub-request-id": "1",
"flags": {}
},
"action": "Restart",
"action-identifiers": {
"vnf-id": "vCPE_Infrastructure_vGMUX_demo_app"
}
}
},
"version": "2.0",
"rpc-name": "restart",
"correlation-id": "a20e2073-30b1-4357-893b-f5ed57b66ef0-1",
"type": "request"
}(4) Response from App-C to Policy
{
"body": {
"output": {
"common-header": {
"timestamp": "2017-08-25T21:06:23.037Z",
"api-ver": "2.00",
"originator-id": "a20e2073-30b1-4357-893b-f5ed57b66ef0",
"request-id": "a20e2073-30b1-4357-893b-f5ed57b66ef0",
"sub-request-id": "1",
"flags": {}
},
"status": {
"code": 400,
"message": "Restart Successful"
}
}
},
"version": "2.00",
"rpc-name": "restart",
"correlation-id": "a20e2073-30b1-4357-893b-f5ed57b66ef0-1",
"type": "response"
}(6) Output of TCA Microservice for Abate Signature
{
"closedLoopControlName": "ControlLoop-vCPE-48f0c2c3-a172-4192-9ae3-052274181b6e",
"version": "1.0.2",
"requestID": "0abc0000-b032-4e4b-bd30-88260f444888",
"closedLoopAlarmStart": 1478189220547,
"closedLoopAlarmEnd": 1478589220547,
"closedLoopEventClient": "DCAE_INSTANCE_ID.dcae-tca",
"target_type": "VNF",
"target": "generic-vnf.vnf-name",
"AAI": {
"generic-vnf.vnf-name" : "vCPE_Infrastructure_vGMUX_demo_app"
},
"from": "DCAE",
"policyScope": "DCAE",
"policyName": "DCAE.Config_tca-hi-lo",
"policyVersion": "v0.0.1",
"closedLoopEventStatus": "ABATED"
}
Day N: Runtime Monitoring of a Control Loop
flow diagram