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

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

  • 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

Step 1

  • No labels