...
- Vijay Kumar
- Filling Dublin gaps and focus on model-driven control loop design.
- Continue conversation with Policy Team to iron out a better strategy to handle Policy-DCAE notifications. One proposal is to have Policy keeping track of <client, filter> pairs, where the filter is a specific condition that needs to be satisfied so as the client can be notified. When the condition is met, PDP notifies DCAE Policy Handler via DMaaP.
- Improve and extend the microservice onboarding process. Today, it's based on TOSCA. The goal is to include other technologies like Helm. This will require also to understand how Policy can support that in the policy model.
- Gervais-Martial Ngueko
- Microservice cloudify blueprint (deployment artifact) and 'control-loop flow service model' distributions should be decoupled, to be clear 'control-loop flow service model' is currently a non-existing artifact meant to describe the control loop flow and not tied to the deployment mechanism(cloudify, kubernetes, helm, whetver,...). SDC shall provide 'control-loop flow service model' , while CLAMP shall receive/generate the microservice blueprints(deployment artifact) in a separate process so as to maintain a catalog of available microservices. This way, users can select which microservice they want for a specific closed loop, with have the possibility to reuse microservices that are already deployed (shared microservice vs. stand alone approach).
- To support the previous point, CLAMP should be able to generate deployment artifacts that are then sent to DCAE. In the current approach, SDC is creating and distributing deployment artifacts.
- To support the previous 2 points, DCAE should expose a 'mS list' API to CLAMP. the 'ms list' API should allow CLAMP to list ALL the running micro-services and the vnf/services they are tied to those micro-services.
- Can we get more support from the community to the closed loop subcommittee?
...