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

Compare with Current View Page History

« Previous Version 8 Next »

Overview

The community ask is to make it easier to design and on-board custom DCAE analytics. Currently, AT (analytic tools) are deployed by DCAE using Cloudify Blueprint. Blueprint is added to service in SDC during design phase and is distributed with service during distribution phase. Blueprint is not verified by SDC or DCAE. CLAMP checks if blueprint contains specific sections like policy-id however it's not verifying if blueprint will instantiate TCA or not. Clamp assumes it's TCA and draws closed loop flow with TCA as AT. There is no ability to use and configure your own custom analytic. Since usage of custom AT is crucial to manage vnf/pnf instance life-cycle in proper way Closed Loop components should support configuring, deploying and working with custom AT.

The main problem that has to be faced is how does other components (Clamp, Policy) know how to configure AT. Currently Policy supports creating various types of policies. Policies relevant with TCA have type Config.Micro-Service. Using it as a type of policy lets you choose field Micro Service. This field decides about parameters that can be defined for policy and by using them Policy creates configuration form for user.

Questions to answer:

  1. What should be format of AC (analytical component) configuration schema?
    1. Idea is to use schema already used in Policy SDK for microservices.
  2. Where provider should put AC configuration schema?
    1. Add new artifact to deployments artifacts.
      1. pros: New artifact with single responsibility can be easily reused.
      2. cons: User has to know that adding DCAE_BLUEPRINT artifact is not enaugh.
    2. Add new field to DCAE_BLUEPRINT (now it's possible for TCA)
      1. pros: No need to new artifact. When adding new AT user is forced to add configuration
      2. cons: It's deployment artifact.
  3. Where ONAP should show form for configuring AC?
    1. Currently it's done in Clamp but Policy is already able to generate form using its schema
  4. Where to save configuration for AC?
  5. How AC should download configuration (and when, what about updates)?
  6. How to provide image of AC. Does it have to be downloaded from some nexus?



Business Requirement

The business requirement is to prepare ONAP Closed Loop components for configuring, deploying and working with custom analytic tool.

Changes in components:

SDC

SDC needs to support adding new configuration schema and distributing it to other component. Schema should match schema currently supported by Policy.

There are two ideas for adding configuration schema to csar:

Add new artifact to deployments artifacts.

  1. pros: New artifact with single responsibility can be easily reused.
  2. cons: User has to know that adding DCAE_BLUEPRINT artifact is not enaugh.

Add new field to DCAE_BLUEPRINT (not it's possible for TCA)

  1. pros: No need to new artifact. When adding new AT user is forced to add configuration
  2. cons: It's deployment artifact.

Policy

Now schemas are add to DB manually. Policy should support adding new schemes of type Config.Micro-Service using REST API. Policy should be able to generate form from schema and let user to configure it.

ToDo: Current implementation seems to be generic. Check if adding custom json matching schema format will make Policy generate proper form.

Clamp

Clamp responsibility is to draw and let user configure closed loop. Clamp should extract appName from DCAE_BLUEPRINT. App name should be used when drawing closed loop. <WORK IN PROGRESS>

Contributions

  • No labels