Versions Compared

Old Version 1

changes.mady.by.user Vijay Kumar

Saved on

compared with

New Version Current

changes.mady.by.user Vijay Kumar

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Removed TCA-gen2 from Dublin and other stretch-goal were delivered

    Project Overview
    CLAMP is the place where you manage the runtime of the Control loop(distributed by SDC) in ONAP:

    1. you can configure the parameters of the µS composing the Control Loop:
      1. this is achieved by creating/updating/deleting policies (configuration policies).
      2. the above policies will be associated to the deployed µS
    2. you can configure the Operation to be taken by the Control Loop:
      1. this is achieved by creating/updating/deleting policies (operational policies).
    3. you can deploy/un-deploy Control Loop flow(blueprint) to DCAE. 
    4. in separated/independent Docker containers, you have the "Control Loop Dashboard" which is an ELK stack dedicated to display DMAAP messages related to runtime control loop messages (from DCAE/Policy/APPC).

  1. Project Overview

    DCAE platform includes components collectively fulfilling the role of Data Collection, Analytics, and Events generation for ONAP. The architecture of DCAE targets flexible, plugable, micros-service oriented, model based component deployment and service composition.

    DCAE also support multi-site collection and analytics operations which are essential for large ONAP deployments. DCAE components generally fall into two categories: DCAE Platform Components and DCAE Services Components.

    DCAE Platform refers the set of controller components which manages the deployment and LCM of the DCAE service components which include all the collectors, analytics and event processor MS. 

     

  2. New component capabilities for Dublin, i.e. the functional enhancements

  3. introduction of the model driven approach for Control Loops

    1. add policy-model to the SDC distribution
    2. automatic rendering of configuration policy ui based on the distributed policy-model 
    3. better rendering of the display of the Control Loop flow based on the distributed blueprint
    4. enhance internal model to better support model driven approach

    Following new components introduced for Dublin

    Collectors

              RESTConf collector            

    Event Processors

              VES/Universal Mapper 
              3gpp PM-Mapper  
              BBS Event processor          

              DL Handlers – Feeder and Admin (POC)

    Analytics/RCA
             SON-Handler (former PCI-Handler)
             Heartbeat 
             TCA-Gen2 (STRETCH GOAL)

    Platform Enhancements

    • Support helm chart deployment in DCAE-C using custom helm plugin*
    • DCAE Healthcheck enhancement
    • Dynamic AAF based topic provisioning
    • Multisite K8S cluster deployment support
    • Dashboard (UI for deployment/verification)
     

  4. New or modified interfaces

    1. User interface generation will stay the same  even though its generation method will change.
    2. Some new internal interface will be created to support the new internal model. those new interface won't be backward compatible since they will be new
      and they are internal anyway(so it won't disturb any other project).
      

  5. Interface naming

    CLAMP supports the following interfaces:

    1. Control Loop Life Cycle Management User interface (LCM UI) for:
      1. selecting the Control Loop flow.
      2. entering configuration policy parameter.
      3. entering operational policy parameter.
      4. manage lifecycle of DCAE blueprint (Control Loop flow).
    2. Control Loop dashboard User Interface based on "Kibana" (ELK stack, completely independent from LCM UI). 
     

  6. Reference to the interfaces

    1. for the UI see readthedocs(obviously still under development for Dublin) : CLAMP latest user guide

    2. internal interface are available via swagger : clamp swagger pdf

  7. What are the system limits

  8. none so far, CLAMP is not a in the path of runtime call, so it is not heavily hit by massive amount of call. So auto scaling is not really required
    but could be added.

  9. DB redundancy/HA relies on kubernetes and persistent volume. mariaDB cluster can be a future improvement

    10. Application redundancy/HA relies on kubernetes

    Architecture diagram - DCAE R4 Architecture Diagram

    New External interfaces

    RESTConf collector (DCAE) - Domain Controllers

    SON-Handler (DCAE) - OOF (via API), SDN (R) (via DMaaP), ConfigDB (via API),  Policy (via DMaaP)

    BBS-eventprocessor (DCAE) - Policy (via DMaaP)

    Heartbeat Ms (DCAE) - Policy (via DMaaP)

    TCA-gen2 (DCAE) - Policy (via DMaaP)


    Modified interfaces

    Policy Handler (DCAE) - Policy (moving to new LC API)

    PRH (DCAE) - AAI (API change based on PNF model update)


    Interface naming

    https://lf-onap.atlassian.net/wiki/display/DW/DCAE+R4+M1+Release+Planning#DCAER4M1ReleasePlanning-APIIncomingDependencies

    Reference to the interfaces


    Existing platform API's - https://onap.readthedocs.io/en/latest/submodules/dcaegen2.git/docs/sections/offeredapis.html

    https://onap.readthedocs.io/en/latest/submodules/dcaegen2.git/docs/sections/apis/deployment-handler.html

    https://onap.readthedocs.io/en/latest/submodules/dcaegen2.git/docs/sections/apis/inventory.html

    https://git.onap.org/dcaegen2/services/prh/tree/swagger.yaml

    https://git.onap.org/dcaegen2/collectors/ves/tree/swagger_vescollector_1.3.1.yaml

    https://git.onap.org/dcaegen2/platform/configbinding/tree/app/app/swagger.yaml


    New R4 APIs to be added into RTD  - SON-Handler, RESTConf

    DCAE R4 M1 Release Planning#APIOutgoingDependencies 


  10. What are the system limits

    Relies on k8s for loadbalancing and scaling. DCAE platform handles the control flow and do not carry the data/event; DCAE service components can be scaled and support state management.
    Cloudify is 3rd party product; multi-site feature on community version will be available later in 2019; will be incorporated for E release.

  11. Involved use cases, architectural capabilities or functional requirements

  12. scaling use cases

    13. model driven Control Loop: Model driven Control Loop Design

    • Usecases

    5G Use Case (Dublin)
            5G - Bulk PM 
            5G - OOF and PCI
    BBS Broadband Service Use Case (Dublin)
    CCVPN (E-LAN Service (EP-LAN, EVP-LAN) *, https://lf-onap.atlassian.net/wiki/pages/viewpage.action?pageId=16323431
    Model Driven Control Loop Requirements

  13. Listing of new or impacted models used by the project (for information only)

    None

    Support for new policy model as required by Model driven control loop requirement.