| Time | Item | Who | Notes |
|---|
| 5min | M2 checklist review | Martial | - Went through the M2 checklist with the team
|
| 25min | Holmes integration discussion | Martial/Pam/Ron/Guangrong | - How to differentiate Holmes VS other policies
- Different structure already available in CLAMP so can use this and do a kind a general parameter that can be used across
- Discussed How to add a new rule or update a rule at runtime ?
- Update a policy is done through the Policy platform and propagate the change to the DCAE controller listening for changes (same should apply to add a policy)
- Agree that for R1 use cases we only need to support one shot instantiation
- Stretch goal to be able to update during runtime for R1 (even though we all agree that should come eventually)
- Designing a Control Loop is done through CLAMP - Ron presented slides to walk through the design of a control loop and actions performed in the CLAMP UI
|
| 2 min | Policy package renaming | Pam/Martial | - Pam informed the team that policy changed from org.openecomp to org.onap and that will affect CLAMP builds
|
| 2 min | Policy API registration in MSB | Pam/Martial | - Policy will have a stretch goal to register their API through MSB, they will still be available as before
|
| 10min | Holmes Correlation update / Use case support | Guangrong/Martial/Ron/Pam | - Update the whole correlation text box will generate an update from CLAMP
- Holmes will be used in vVOLTE use case closed loop and thus will only support 1 instance
- If multiple use case were to be run, that would generate multiple instance of the control loop (eg for TCA)
- in the case of Holmes there will only be 1 instance but that is decided by DCAE
- handling multiple default rules for Holmes inside CLAMP is a stretch so look for merge into a single default rule file
|
