Assumptions in Beijing Release

• There is no mechanism in place for automated triggering of DCAE service assurance deployment, i.e. DCAE microservice instantiation and configuration will be driven by CLAMP
• The DCAE Design Studio will not generate any policies in Beijing
• CLAMP expects DCAE Design Studio to:
  • Onboard any necessary microservices for the flows (together with DCAE team)
  • Generate TOSCA Service Template describing the flow
  • Generate Cloudify Blueprint
  • Store both service template and blueprint in SDC catalog as part of Service/Resource instance
  • Distribute these service assurance artifacts for consumption by DCAE and CLAMP

Definitions

• Single (shared) deployment flow
  • Example: Holmes
• Multiple (dedicated) deployment flow
  • Example: TCA
• For Holmes, as a shared deployment, do we deploy it from CLAMP or pre-deploy it together with DCAE
  • If pre-deployed, is there any way that CLAMP can know its status?

Full Flow

Design Flow

Step 1

• A service designer uses DCAE Design Studio to attach a service assurance flow to a service definition in the SDC catalog
• DCAE Design Studio will not be used to create flows
• Microservices will be onboarded to DCAE using component specification, and TOSCA Lab will be used to generate the flow
• The artifacts created through this process
  • Service Template
  • Policy TOSCA files
  • Blueprint
• This process will create flows for the following microservices:
  • TCA-hi-lo
  • Holmes
• The flow will only contain a single microservice node and two topics
• It is assumed that the input topic will receive data from VES Collector
• It is assumed that the output topic sends data to Policy Engine to be processed by Drools PDP
• The policyId parameter in the policy node will be set as follows:
  • For a pre-deployed microservice that will not be redeployed by CLAMP, a prefix value will be set
  • For a microservice that CLAMP will deploy, this policyId parameter will be set to the value of a policyId input in the service template and blueprint
• After selecting the predefined service assurance flow described above, the user saves service assurance flow as an artifact of a resource instance within a service
• This is followed by testing, certification and distribution of the service

Step 2

• CLAMP uses distribution client to receive update
• CLAMP receives artifacts:
  • Service template TOSCA
  • Policy TOSCA
  • Blueprint
• CLAMP receives the following data from SDC
  • Service Invariant UUID
  • Resource Invariant UUID
  • Artifact name of blueprint
  • Service name
  • Resource name
• CLAMP stores data about control loop in local store by: 
  • Service Invariant UUID, Resource Invariant UUID, Artifact name of blueprint, Service name, Resource name
    
    
  Below is an example fragment of an SDC distribution sent to CLAMP which provides the data that it needs.

HTTP/1.1 200 Ok
Content-Type : application/json
Content-Length : …


{
                "distributionID": "34cb001c-c9f0-4db9-b59c-9421c0b3cb5e",
                "serviceName": "HNGW Protected OAM",
                "serviceVersion": "1.0",
                "serviceUUID": "b8ff69ca-786d-479e-9f9c-217a90ee0ebc",
                "serviceDescription": "HNGW Protected OAM Network Service",
                "serviceInvariantUUID": "c2749b42-28db-45e0-ab55-b05d0118d91d",
                “resources”: [
                {
                                "resourceInstanceName": "oam_net",
                                "resourceCustomizationUUID": "7b1383b5-6b84-4e77-ae26-1778a1f4e7e1",
                                "resourceName": "ExtVL",
                                "resourceVersion": "1.0",
                                "resoucreType": "VFC",
                                "resourceUUID": "9bf1978e-d6b9-47fc-a4cd-cc8ec4e461b7",
                                "resourceInvariantUUID": "38e5fb81-5e8c-479b-9140-38786db19967",
        						"category": "Generic",
        						"subcategory": "Network Elements",
                                "artifacts": [
								{
                                	"artifactName":"AAI-service_HNGW_Protected_OAM-service-1.xml",
                                	"artifactType":"DCAE_INVENTORY_TOSCA",
                                	"artifactURL":"/sdc/v1/catalog/services/HngwProtectedOam/1.0/artifacts/AAI-service_HNGW_Protected_OAM-service-1.xml",
                                	"artifactChecksum":"ODc1NzViNzY4Mzc1NGE4NTc3M2VhOTM0NTkyZjRiYTA\u003d",
                                	"artifactDescription":"AAI Service Model",
                                	"artifactTimeout":0,
                                	"artifactUUID":"5791d7b0-1a20-4066-90d0-ef13bbf01c95",
                                	"artifactVersion":"1"
								},
								{
							    	"artifactName":"service-TestServicecsar.csar",
									"artifactType":"DCAE_INVENTORY_BLUEPRINT",
									"artifactURL":"/sdc/v1/catalog/services/HngwProtectedOam/1.0/artifacts/service-HngwProtectedOam-csar.csar",
									"artifactChecksum":"YzhhNTVhZDk2M2RlN2NlODkzODk5ZGJjOThmNDY1MzE\u003d",
									"artifactDescription":"TOSCA definition package of the asset",
									"artifactTimeout":0,
									"artifactUUID":"909e655d-04d6-472b-ab16-979d560d1975",
									"artifactVersion":"1" 
								}
								]
                }],
                "serviceArtifacts": [{}]}

Step 3

Configuration Flow

Configuration Step 0

• CLAMP parses service template

• Assumptions:

• Service template consists of multiple node templates

  • Topics

  • Microservices 

  • Policies

• Microservice: Any node template with a subtype of tosca.dcae.nodes.cdapApp (or some other type such as tosca.dcae.nodes.dockerApp?)

• Topics: Any node template with a type of tosca.dcae.nodes.dmaap.topic

• Policies: Any node template with a type of tosca.dcae.nodes.policy

• There will be only one Microservice node

• The microservice node will have two requirements that are fulfilled by topics: one stream subscribe and one stream publish

• The two topic nodes will be included in the service template

• The microservice node will have a requirement for a policy node, and policy node will be included in the service template

• Processing Steps

  • Display any microservice node template

  • Display inputs provided to blueprint

  • Display topics which are used to connect microservice node templates

  • Retrieve configuration policies and prepare to display and encode

  • For each microservice node template, identify the node template which fulfills the policy requirement

  • Retrieve the policy TOSCA corresponding to this policy node, using policyName parameter

    • (Only needed if there are multiple microservice nodes: Identify the microservice node template which is the last in the flow before the Operational Policy)

    • Display the Operational Policy as a box after the last (or only) microservice node template

• A flow will either be deployed once for all control loops (shared) or deployed per control loop (dedicated)

• The microservice node will have a parameter that defines whether it should be a shared or dedicated microservice

• CLAMP will use this parameter to decide whether or not to deploy it

• Can user edit template inputs that are required

  • Examples: policy Ids, Topic URLs and AAF credentials (needed to clarify this)

  • Some cannot be edited, such as policy Id; CLAMP must be provided

  • Some may be set in configuration files in CLAMP

  • User can edit any configuration policy in a separate popup created using TOSCA policy model

  • User can edit operational policy in a separate popup created as is done today, based on local CLAMP configuration

Configuration Step 1

• CLAMP sets the input whose value is used to set policy_id parameter in the node template
  • If the flow is a shared deployment, and has not yet been deployed, choose a policy prefix
  • If the flow is a shared deployment and has been deployed, no input needs to be set, because blueprint will not be deployed
  • If the flow is a dedicated deployment
• Data from Configuration and Operational Policies is used to create policies
• Need to create associated controlLoopIds in Configuration and Operational policies 

Deployment Flow

• This step only applies when the flow is deployed by CLAMP
• Call deployment handler
• Refer by service UUID, resource UUID and name
• Provide inputs:
  • policyId
  • Topic information
  • AAF authentication
  • Others?
• Check on deployment status
• Allow undeploy and redeploy

Suspend Flow

• Currently the only way to stop a control loop is by deleting the operational policy
• This is the operation that CLAMP will use

Update Flow

• User makes updates via CLAMP UI
• CLAMP updates either  microservice configuration or Operational Policies in the Policy Repository.
• Microservice configuration policy changes are pushed to DCAE through Policy Handler

Monitoring