/
CLAMP Desired Functionality Post-Beijing

CLAMP Desired Functionality Post-Beijing

Owned by Ron Shacham
Last updated: Dec 11, 2018 by Adam Krysiak
3 min read

We list here functionality that should be integrated into CLAMP in the coming releases.  Inclusion into Casablanca or any other release will depend on resource availability.

  1. (Modeling/Generic) Enhance TOSCA Policy model support. This will improve flexibility to allow runtime possibility to add new type of mS into CLAMP: 

    1. Better parsing of TOSCA Policy model.

    2. get policy definition from policy API(if API available) or SDC (or manually). This will allow runtime knowledge of mS configuration pattern.

  2. (Modeling/Generic) Improve blueprint/service template parsing of Control Loop definition coming from DCAE-D:

    1. Move from "blueprint"(tied to Cloudify orchestration) to "service_template"(more generic Tosca file and independent from orchestration type) for Control Loop description/definition.

    2. better definition of flow that includes collector, operational policy, etc.

  3. “MariaDB+Galera cluster” (helm chart to be provided by OOM team in Casablanca).

  4. (filtering) Generic filtering mechanism to associate a Control Loop to the Network, Policy filtering to specify the control loop behavior at various granularity. CLAMP creates policy that describes the filter, which is coupled with operational policy.  (Policy is still deciding whether this would be guard policy or another type) The filter would be based on the data provided by A&AI:

    1. VNF instance 

    2. VNF location

    3. Based on customer

    4. Based on revenue-generating vs.

    5. VNF type

    6. ....

  5. (filtering) A&AI integration to get realtime view of network topology.  This will support capability to specify filters for control loop operational policies (item 1)..

  6. A faster way to disable/re-enable a Control Loop at runtime(currently there is several steps involved: stop/undeploy/....)

    1. disable/re-enable Control loop at different level, e.g.: disable for some VNF inside a service instead of disabling for all VNF inside the service.

    2. show, into a runtime dashboard view, the condition which are disabled on that Control loop.

  7. (Dashboard/UI) UI Enhancements for dashboard and UI

    1. filtering of events in dashboard (location, vnf, control loop)

    2. ability to see end-to-end control loop events

    3. better view of status of control loop deployment - where things have succeeded or failed

  8. (Dashboard/UI) Improve dashboard integration into CLAMP UI. (currently only 2 separates UI kibana/CLAMP UI) but we need a bridge in CLAMP UI towards kibana reports for specific KPI’s (to be discussed with Ops.)

  9.  

    1. provide dashboard (through elastic search) with deployment-related events from CLAMP to know the status of control loop management. Not Necessary for Operation at this point !!!, only point might be authorization using the main CLAMP UI to allow access

  10. Add a CLI functionality, to improve the automation part, enabling automation for script type provisionning (hundres, thousands...) of control loops.

    1. the CLI might be based on REST API exposed by CLAMP. so the CLI could be a wrapper around API's that CLAMP would expose

  11. Add functionality to pickup Control Loop which would have been createdexternally by another system than CLAMP. This would imply:

    1. discovering corresponding micro-services in DCAE

    2. discovering matching policy which control the above micro-services 

  12. Integrate CLAMP and policy UI better: the goal could be to directly create CLAMP policies in Policy UI

  13. Expose file globalProperties.json in OOM installation like it's done for sdc-controllers-config.json. This would let users to change possible actions, events etc. with just single change in globalProperties.json in oom. This won't be necessary when Event based Common Notification messaging format for Control Loop Operations is finished.

  14. Improve error handling e.g:

    1. When deploying CL and process fails User doesn't know what happened. Sometimes it's small issue like invalid port. If user would know it he can instantly redeploy with correct parameters

  15. Expose user friendly endpoint for setting log level in runtime (e.g. we can use spring boot actuator )