...
- DCAE to Policy: Vijay Venkatesh Kumar updated TCA and VES data is now processed by collector and TCA and output from TCA is observed on unauthenticated.DCAE_CL_OUTPUT. Policy does observe that event from TCA. But the closed-loop name is incorrect. Vijay Venkatesh Kumar will load the correct TCA Policy listed on Policy R1 Amsterdam Functional Test Cases and the test will continue next week.
- APPC to MultiCloud: Problems from the previous days have been fixed. Scott Seabolt tested through Swagger UI and identified a new problem caused by prefix spaces in DG. He will fix it soon.
- vGMUX: Eric Multanen has identified how to configure VES collector: one has to delete the current VES collector setting before setting a new one. This applies to both command line and API configuration. A question raised is that the current VES event uses VM name and VM ID. What we use in AAI is actually the VNF ID. Need to figure out how to set that VNF ID in vGMUX.
- From Eric: The "sourceName" and "sourceId" in the event data are generated by 'libevel.so' which comes from source code in demo/vnfs/VES5.0/evel/evel-library/code/evel_library. These elements are currently populated by openstack metadata corresponding to the vm name and vm id. The vG-MUX server has a property vnf_id='vCPE_Infrastructure_vGMUX_demo_app' - so it is presumably feasible to modify the libevel.so code to use this value (the same one for both 'sourceName' and 'sourceId' ?). The question is: should this be a quick and dirty hack for the vG-MUX VNF specifically? or, a more general fix in the library code? I'd be worried about changing the library code in the 'demo' repository and breaking some other use case or demo.
- From Kang:
- A quick hack should be good enough. In this use case, we only need vGMUX to report events so the other VNFs do not need a similar hack.
- Let's give vnf_id to both sourceName and sourceId. In principle only sourceId should be used by DCAE. But my test shows that only sourceName is used instead. Since vnf_id is specified in the HEAT and there is no sourceName at all in the HEAT, the above approach should work well to avoid potential inconsistency.
- Meeting recordings:
...