Discussion items
| Duration | Agenda Item | Requested by | Notes / Links |
|---|---|---|---|
| START RECORDING | |||
Please be aware of the following week: 2019 Silicon Valley Meeting Proposals Control Loop meeting 9am PST on (tentative - please watch schedule to confirm) | |||
Vote to keep or cancel the regular Control Loop meeting on - Pam will be unavailable again. | Closed loop subcommittee meeting scheduled for April 3, 2019 is canceled due to conflict with ONS | ||
| CSAR Review | |||
ATTENDEES
NOTES
Marco Platania Pamela Dragosh Vijay Venkatesh Kumar will participate to the next ONAP F2F meeting.
...
- Vijay Venkatesh 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 blueprint and 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?
...