Skip to end of metadata
Go to start of metadata

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

Compare with Current View Page History

« Previous Version 8 Next »

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



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",

                “reources”: [

                {

                                "resourceInstanceName": "oam_net",

                                "resourceCustomizationUUID": "7b1383b5-6b84-4e77-ae26-1778a1f4e7e1",

                                "resourceName": "ExtVL",

                                "resourceVersion": "1.0",

                                "resoucreType": "VL",

                                "resourceUUID": "9bf1978e-d6b9-47fc-a4cd-cc8ec4e461b7",

                                "resourceInvariantUUID": "38e5fb81-5e8c-479b-9140-38786db19967",

        "category": "Generic",

        "subcategory": "Network Elements",

                                "artifacts": []

                }],

                "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

  • No labels