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.
- (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:
- VNF instance
- VNF location
- Based on customer
- Based on revenue-generating vs. not
- (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).
- (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.)
- provide dashboard (through elastic search) with deployment-related events from CLAMP to know the status of control loop managment
- (Dashboard/UI) UI Enhancements for dashboard and UI
- filtering of events in dashboard (location, vnf, control loop)
- ability to see end-to-end control loop events
- better view of status of control loop deployment - where things have succeeded or failed
- (Modeling/Generic) Enhance TOSCA Policy model support. This will improve flexibility to allow runtime possibility to add new type of mS into CLAMP:
- Better parsing of TOSCA Policy model.
- get policy definition from policy API(if API available) or SDC (or manually). This will allow runtime knowledge of mS configuration pattern.
- 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.)
- Improve blueprint (Modeling/Generic) Improve blueprint/service template parsing of Control Loop definition coming from DCAE-D:
- Move from "blueprint"(tied to Cloudify orchestration) to "service_template"(more generic Tosca file and independent from orchestration type) for Control Loop description/definition.
- better definition of flow that includes collector, operational policy, etc.
- “MariaDB+Galera cluster” (helm chart to be provided by OOM team in Casablanca).Generic filtering mechanism to associate a Control Loop to the Network, Policy filtering to specify the control loop behavior at various granularity. the filter would be based on the data provided by A&AI:
- VNF instance
- VNF location ...
- A faster way to disable/re-enable a Control Loop at runtime(currently there is several steps involved: stop/undeploy/....)
- 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.
- show, into a runtime dashboard view, the condition which are disabled on that Control loop.
- .
- Add a CLI functionality, to improve the automation part, enabling automation for script type provisionning (hundres, thousands...) of control loops.
- 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
- Add functionality to pickup Control Loop which would have been createdexternally by another system than CLAMP. This would imply:
- discovering corresponding micro-services in DCAE
- discovering matching policy which control the above micro-services
- Integrate CLAMP and policy UI better: the goal could be to directly create CLAMP policies in Policy UI
...