You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 53 Next »

10/17/2017

cloud-region.jsonbase_vcpe_vgmux.envvcpe.rc

10/16/2017

  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  DCAEGEN2-164 - Getting issue details... STATUS .
    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.
  3. Eric Multanen has fixed the even data content problem to include the correct vnf_id passed from the HEAT. See details appended by Eric to to 10/13/2017 notes.

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.

    3. From Eric:

      Below is output of the updated event data - check the bold items to verify this is what is desired (note:  "vCPE_Infrastructure_vGMUX_demo_app" is the value of the "vnf_id" property from the OpenStack metadata of the vG-MUX VM):

      {"event": {"commonEventHeader": {"domain": "measurementsForVfScaling", "eventId": "Generic_traffic", "eventName": "Measurement_vGMUX", "lastEpochMicrosec": 1508188493486856, "priority": "Normal", "reportingEntityName": "zdcpe1cpe01mux01", "sequence": 55, "sourceName": "vCPE_Infrastructure_vGMUX_demo_app", "startEpochMicrosec": 1508188483486856, "version": 1.2, "eventType": "HTTP request rate", "reportingEntityId": "No UUID available", "sourceId": "vCPE_Infrastructure_vGMUX_demo_app"}, "measurementsForVfScalingFields": {"measurementInterval": 10, "cpuUsageArray": [{"cpuIdentifier": "cpu1", "cpuIdle": 100.000000, "cpuUsageSystem": 0.000000, "cpuUsageUser": 0.000000, "percentUsage": 0.000000}], "requestRate": 9956, "vNicUsageArray": [{"receivedOctetsDelta": 0.000000, "receivedTotalPacketsDelta": 0.000000, "transmittedOctetsDelta": 0.000000, "transmittedTotalPacketsDelta": 0.000000, "valuesAreSuspect": "true", "vNicIdentifier": "eth0"}], "additionalMeasurements": [{"name": "ONAP-DCAE", "arrayOfFields": [{"name": "Packet-Loss-Rate", "value": "0.0"}]}], "measurementsForVfScalingVersion": 2.1}}}

  4. Meeting recordings: 
    1. GMT20171013-135015_Kang-Xi-s-_1920x1200.mp4
    2. GMT20171013-191357_Kang-Xi-s-_1920x1200.mp4

10/12/2017

  1. AAI has a problem to pre-load data using this script closed-loop-biny993.zip, tracked by  AAI-433 - Getting issue details... STATUS .
  2. Ethan Lynn has created a doc to show to register VMWare Openstack Fake Cloud into AAI and how to use it: https://gerrit.onap.org/r/#/c/18493/1/docs/Multicloud-Fake_Cloud-Guide.rst
  3. ESR installation guide: http://onap.readthedocs.io/en/latest/submodules/aai/esr-server.git/docs/platform/installation.html
  4. DCAE TCA is tracked by  DCAEGEN2-158 - Getting issue details... STATUS .

  5. Eric Multanen continues to fix vGMUX and made good progress. vGMUX in the ONAP-vCPE work space is now reporting VES data. Some fixes are needed. This is tracked by  INT-275 - Getting issue details... STATUS .

10/11/2017

  1. Test plan for CLAMP (Ron Shacham, Gervais-Martial Ngueko, Xue Gao, Lusheng Ji, Vijay Venkatesh Kumar):
    1. Integration team will install ONAP in a separate work space and let CLAMP do the testing. This is tracked in  INT-271 - Getting issue details... STATUS .
    2. CLAMP will start by test with Policy and SDC on the design part. The goal is to configure Policy and create Blueprint template for DCAE.
    3. Currently DCAEGEN2 cannot be installed in the open lab due to the lack of Openstack Designate support. This is expected to be fixed in a few days. In the meanwhile, CLAMP will do pairwise test with DCAE in the AT&T internal environment in parallel.
  2. MultiCloud (Bin Yang, Ethan Lynn)
    1. MultiCloud sending query to AAI to obtain cloud info passed.
    2. MultiCloud performing VM restart (two commands: stop followed by start) passed. This was done by manually posting to the MultiCloud broker API.
    3. A VMWare VIM is simulated and passed VM restart test.
    4. Normally VIM is registered to ESR, and ESR will populate AAI with the cloud info. In this test, Bin Yang used a script to preload AAI with such info. MultiCloud queries AAI using VIM-ID to get the cloud info to do actual cloud operations.
  3. APPC→MultiCloud to restart VNF (Scott Seabolt, Ryan Young, Randa Maher)
    1. A bug is discovered inside APPC, tracked by APPC-268 - Getting issue details... STATUS .
  4. DCAE (Vijay Venkatesh Kumar)
    1. With the sampe VES provided by Eric Multanen on 10/10, the team has updated the TCA policy accordingly and will load it to TCA later today. It is tracked by  DCAEGEN2-135 - Getting issue details... STATUS .
    2. Note that in the final release, this TCA policy will be designed either using CLAMP or Policy GUI and distributed. No manual loading is needed.
  5. vGMUX (Eric Multanen)
    1. Eric is debugging vGMUX in his environment. Once it is done, he will see if it is feasible to create a VM image and use the image in the open lab instead.
  6. VxLAN config using SDNC
    1. We suggest that SDNC generates the VxLAN config request and send them to Eric Multanen to verify the correctness. It will help the upcoming pairwise test once the VNFs are ready in the open lab. This is tracked by  SDNC-120 - Getting issue details... STATUS .
  7. Customer flow testing in SO
    1. Update from Saryu Shah and BORALE, SHAILENDRA S <sb8915@att.com>: 

      The custom flow testing was performed using Junit testing.

      “mvn install” in so/bpmn/MSOInfrastructureBPMN will runs all the tests.

      Test is self-contained and all the required data files and simulator code was checked in. As of now, Jim is in the process of checking in bug-fixes.

  8. Meeting recording: GMT20171011-140734_Kang-Xi-s-_1920x1200.mp4

10/10/2017

  1. APPC: Scott Seabolt used Swagger API to invoke VNF restart. APPC passed AAI named query. The DG in APPC failed to query AAI because it did not point to the correct AAI. This is tracked by  APPC-267 - Getting issue details... STATUS .

  2. vGMUX: Eric has created a sample VES data as shown below. DCAE needs to be adjusted to process the data. This is tracked by DCAEGEN2-147 - Getting issue details... STATUS . Eric is also working to fix vGMUX.

    vCPE VES data
    {"event": {"commonEventHeader": {"domain": "measurementsForVfScaling", "eventId": "Generic_traffic", "eventName": "Measurement_vGMUX", "lastEpochMicrosec": 1507676920903343, "priority": "Normal", "reportingEntityName": "vg-mux", "sequence": 1, "sourceName": "Dummy VM name - No Metadata available", "startEpochMicrosec": 1507676910903343, "version": 1.2, "eventType": "HTTP request rate", "reportingEntityId": "No UUID available", "sourceId": "Dummy VM UUID - No Metadata available"}, "measurementsForVfScalingFields": {"measurementInterval": 10, "cpuUsageArray": [{"cpuIdentifier": "cpu1", "cpuIdle": 85.700000, "cpuUsageSystem": 14.300000, "cpuUsageUser": 0.000000, "percentUsage": 0.000000}], "requestRate": 9383, "vNicUsageArray": [{"receivedOctetsDelta": 0.000000, "receivedTotalPacketsDelta": 0.000000, "transmittedOctetsDelta": 0.000000, "transmittedTotalPacketsDelta": 0.000000, "valuesAreSuspect": "true", "vNicIdentifier": "eth0"}], "additionalMeasurements": [{"name": "ONAP-DCAE", "arrayOfFields": [{"name": "Packet-Loss-Rate", "value": "49.0"}]}], "measurementsForVfScalingVersion": 2.1}}}
  3. Meeting recording: GMT20171010-181134_Kang-Xi-s-_1920x1200.mp4

10/9/2017

Closed loop control test is decomposed into the following items.

  1. Design and load policy rules to policy engine. Jorge Hernandez created a closed loop for vCPE. Policy is tested by posting a DCAE TCA event on DMaaP. Policy reacted by sending an event to APPC to trigger VNF restart. The message format needs to be fixed, see POLICY-300 - Getting issue details... STATUS . And the topics need to be added to APPC properties, see  APPC-265 - Getting issue details... STATUS .

  2. Scripts are created to preload AAI. Scott Seabolt tested them in the integration environment. Both preloading and named query works.
    closed-loop.zip contains the necessary data (json) as well as shell scripts to load the Integration vGMUX.  Note the attached files load data specific the the "vCPE_Infrastructure_vGMUX_demo_app" VNF.  If you'd like to load a different VNF each of the json files owuld need to be modified to reflect the new VNF.

    1. put_closed_loop.sh

      • usage: put_closed_loop.sh A&AI-IP
    2. verify.sh
      • usage: verify.sh A&AI-IP
  3. VES collector is working. Waiting for sample VES data from Eric Multanen. See  DCAEGEN2-135 - Getting issue details... STATUS . Once the data is available, the TCA policy on Policy R1 Amsterdam Functional Test Cases may need to be adjusted and then TCA testing can be performed.
  4. vGMUX cannot be properly instantiated. Eric Multanen, Marco Platania, and Kang Xi are working to solve it.
  5. Docker info shows that the multi-cloud services are running inside the open-o VM as multiple containers
    1. The VM is vm1-openo-server with IP 10.12.25.113
    2. Service ports are listed below. More details of each service are described on Setup MultiCloud Development Env 
      1. broker: 9001
      2. VIO plugin: 9004
      3. Ocata plugin: 9006
      4. WindRiver plugin: 9005


Meeting recording is GMT20171009-170725_Kang-Xi-s-_1920x1200.mp4

10/6/2017

Closed loop control test is decomposed into the following items.

  1. Design and load policy rules to policy engine. Ideally this should be done by CLAMP. Currently CLAMP is working on CLAMP-59 - Getting issue details... STATUS . The workaround is to use Policy GUI. Jorge Hernandez will work on this.

  2. Preload AAI with vCPE data. The purpose is to lookup vServer using vGMUX VNF ID. Scott Seabolt (APPC) will provide a sample data to Venkata Harish Kajur (AAI) to show the named query. Venkata Harish Kajur will then create a script to preload such data to AAI for the testing.

  3. vGMUX sends packet loss VES to DCAE VES collector.

    • Kang Xi created a vGMUX instance in the open lab but the VPP-based VNF inside the VM is not functioning. According to Eric Multanen, most likely it is caused by network issues. Eric is working on this. Kang will also inform Danny Zhou and Johnson Li about this.

    • The following VES data caused an error. The most possible reason is that the data itself is incorrect. Vijay Venkatesh Kumar is looking into that.

      VES Data
      curl -H "Accept: application/json" -H "Content-Type: application/json" -d '{"event":{"measurementsForVfScalingFields":{"measurementInterval":10,"measurementsForVfScalingVersion":1.1,"vNicUsageArray":[{"multicastPacketsIn":0,"bytesIn":4300,"unicastPacketsIn":0,"multicastPacketsOut":0,"broadcastPacketsOut":0,"packetsOut":0,"bytesOut":0,"broadcastPacketsIn":0,"packetsIn":101,"unicastPacketsOut":0,"vNicIdentifier":"eth1"}]},"commonEventHeader":{"reportingEntityName":"zdfw1fwl01fwl01","startEpochMicrosec":1500379662497999,"lastEpochMicrosec":1500379672497999,"eventId":"1","sourceName":"zdfw1fwl01fwl01","sequence":1,"priority":"Normal","functionalRole":"vFirewall","domain":"measurementsForVfScaling","reportingEntityId":"No UUID available","sourceId":"75ec15e4-1a9a-4ee3-bb3c-31556903558d","version":1.2}}}' 10.12.25.84:8080/eventListener/v5

  4. DCAE TCA sends an event to Policy through DMaaP. This is tested as described in  DCAEGEN2-124 - Getting issue details... STATUS

  5. Policy process the event from DCAE, and then sends a “restart” event to APPC through DMaaP. Jorge Hernandez will work on this.

  6. APPC captures the event from Policy, performs a named query to AAI to get the vServer ID based on the VNF ID, and then restarts the VM through MultiVIM. 

    • APPC is working on some changes and will be able to test next week. 
    • There should be a MultiVIM VM in the stack but we don't see any. Refer INT-258 - Getting issue details... STATUS  to track this problem.

In addition, the bottom of Policy R1 Amsterdam Functional Test Cases shows important sample data for vCPE test cases.

Update:

  • Scott Seabolt created the data pertaining to the vGMUX in POD25 which needs to be inventoried in POD25 A&AI. Venkata Harish Kajur then created a script to preload AAI with the following instructions: "Unzip this closed-loop.zip and go into closed-loop directory and run the ./put_closed_loop.sh ${AAI_VM1_IP_ADDRESS} And then you can verify that it works by doing a ./verify.sh ${AAI_VM1_IP_ADDRESS} and it should return you that named query response that you sent me."
  • Meeting recording

Related Documents:

  1. VNF Doc: ONAP vCPE VNF Installation Guide v1.docx


  • No labels