Versions Compared

Old Version 42

changes.mady.by.user Kang Xi

Saved on

compared with

New Version 43

changes.mady.by.user Kang Xi

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. DCAE to Policy: Vijay Venkatesh Kumar has fixed TCA policy to put in the correct closed loop name. However, multiple problems exist in the TCA output, tracked by 
    Jira
    serverONAP JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keyDCAEGEN2-164
    .
    1. Fixed vCPE policies on the wiki to use VNF as the controlLoopSchemaType. 
    2. Fixed TCA jar to include "version" as is needed by Policy.
  2. Passed test: → DCAE → Policy → . Manually fed a VES data to DCAE, observed an event from Policy to APPC.
    1. Note that currently Policy does not check the time stamp in the event so for testing purpose there is no need to increase the time stamp in the VES data.
    2. Once Policy sends out a restart event to APPC, it will not send another restart event until the current operation is completed or time expires even if it receives subsequent ONSET events. To retest in case operation fails in APPC, Policy needs to be restarted.

10/13/2017

  1. 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.
  2. 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.
  3. 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.
    1. 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.
    2. From Kang: 
      1. 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.
      2. 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.
      3. Update based on communication with John Choma: VNF UUID is the same as VNF ID used in the HEAT.
  4. Meeting recordings: 
    1. GMT20171013-135015_Kang-Xi-s-_1920x1200.mp4
    2. GMT20171013-191357_Kang-Xi-s-_1920x1200.mp4

...