You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

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 DCAE_Developer
	entity DCAE_Comp_JSON
	participant DCAE_TOSCA_Tool
	entity DCAE_TOSCA
end box
box "SDC GUI" #f4c69f
	participant SDC
	database SDC_Catalog
	end box
autonumber
loop for all DCAE Components
DCAE_Developer -> DCAE_Comp_JSON : Offline creates JSON schema\nspecifying the metadata\nrequired by this component.\nInputs\nOutputs\nConfiguration
DCAE_Comp_JSON -> DCAE_TOSCA_Tool : Uses TOSCA tool to\ncreate artifact.
DCAE_TOSCA_Tool -> DCAE_TOSCA : TOSCA Artifact created.
DCAE_TOSCA -> 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.


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 during Service Design for designing Control Loop Blueprints via CLAMP.
actor Service_Designer
participant SDC
database SDC_Catalog
entity Service_1 #ffb266
entity VNF_Artifact #b266ff
participant CLAMP
participant Policy
database Policy_Repo
autonumber
Service_Designer -> SDC : Log into SDC
SDC -> SDC : Create service
loop for all VNFs
note right
	For simplicity, assume the designer
	will create a control loop per VNF.
end note
SDC_Catalog -> VNF_Artifact : Find artifact
VNF_Artifact -> Service_1 : Add VNF to service.
SDC -> CLAMP : Go to CLAMP\nto create a Control Loop
CLAMP -> SDC_Catalog : Find DCAE Template
create collections DCAE_Template_1 #red
CLAMP -> DCAE_Template_1 : Select DCAE Template\nand create a working model\nof the Control Loop.
create collections Model_1 #00FFFF
DCAE_Template_1 -> Model_1 : Now designing a model\nbased on the template.
loop for all DCAE Components in Template (now Model)
Model_1 -> Model_1 : Configure the\nDCAE Component as desired.
Model_1 -> Policy : Create DCAE Component\nConfig Policy based on default TOSCA
create entity Config_Policy #green
Policy -> Config_Policy : Creates XACML
Config_Policy -> Policy_Repo : Stores runtime\config policy.
Policy -> Model_1 : Returns Policy ID
end loop
Model_1 -> Policy : Create Operational Policy
create entity Op_Policy #green
Policy -> Op_Policy : Using a Drools\ncontrol loop template,\na policy is created for\nthis specific control loop.
Op_Policy -> Policy_Repo : Stores runtime operational policy.
Policy -> Model_1 : Returns Policy ID
Model_1 -> SDC_Catalog : Generate "BLUEPRINT" and save to catalog
end loop
SDC -> SDC_Catalog : Save service to database
@enduml



example of policies, blueprints, api calls. etc.


Day N: Runtime Monitoring of a Control Loop

flow diagram






  • No labels