Versions Compared

Old Version 2

changes.mady.by.user Ron Shacham

Saved on

compared with

New Version 3

changes.mady.by.user Ron Shacham

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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 input from DCAE, Policy and CLAMP)
    • Generate TOSCA Service Template describing the different parts of the flow: source, collector, analytics, operational policy reference/placeholder
    • 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


Full Flow


Image Added

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
  • 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


Step 3

Deploy Flow

Image Added

Deploy 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

Step 3

Step 1

...

  • 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

Deploy Step 1

  • 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

Deploy Step 2

Stop Flow

Image Added

  • 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

Image Added

  • 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

Image Added