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.
Topics that should be covered during 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 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 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.
- Can we get more support from the community to the closed loop subcommittee?
Gervais-Martial Ngueko Sébastien Determe The policy model in the CSAR file is not in the format we expected (single yaml file). It is composed of policies.yml and data.yml files. CLAMP Team is proposing to rework this in background, by creating an in-memory tree that includes the data.yml imported by the policies.yml file to link policy and data types so as to build a template that CLAMP can use to render the GUI. CLAMP Team will follow up about feasibility of this plan (it should be feasible but it needs investigation).